Язык Java уйдёт в прошлое после выпуска версии 7?

Кто не знает в 7 версии виртуальная машина сможет обрабатывать целый ряд языков программирования, помимо явы. И при том совместимость с написанными ранее библиотеками останется. Что это сулит? Падение зарплат Java программистов? или вымирание java и заменой его более быстрым для написания языком?

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Идиоты пишут статьи. Потом далекие люди начинают гадать

Опсуждать производительность джавы уже давно не в моде, люди, вы чо: -)

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

Про яку швидкість виконання/написання йде мова? Вся різниця буде в тому шо зможемо писати наприклад System-> out-> println ( «C++» ); замість System.out.println ( «Java» ); По суті нічого не змінить крім збільшення бидлокодерів (котрі будуть думати що перейти з делфі на «джавішне» делфі, ніж на Java)

Швидкість виконання коду не зміниться так як з всіх мов код інтерпретується як джавабайткод і вже лише його виконання буде впливати на швидкодію.

Вчера в radio-t состоялась интересная дискуссия на тему «C++ отстой? Ну, не совсем и совсем нет», в том числе и про Java и про всякие Python вспоминали.

никто не спорит, но есть часть товарищей, которые упорно доказывают, что «правильная» виртуальная машина == панацея. И что джава в конечной скорости переплюнет С++ (хорошо хоть с простым си не пытаются сравнивать:))

Странные характеристики «Java быстрее С++» или наоборот.

Странные сравнения дрели и отвертки. Это разные инструменты, с разными областями применения. Джава быстра в разработке, тормозит в исполнени. С++ наоборот. Каждый выбирает, что ему важнее.

Странные характеристики «Java быстрее С++» или наоборот.
И Java и С++ прежде всего ЯП, набор ключевых слов «естественного английского» и операций. Со временем будут появлятся новые

ЯП, более удобные и новые переводчики для новых железок. Расслабтесь, мы в Нирване...

Ну, а уж подобрать специальный тестовый пример, в котором современная JVM разгромит конкретный современный популярный C/C++ рантайм не так уж и нереально.

вот прямо вот так:) «Разгромит»:)
более умереные джависты хоть пишут чтото типа «практически сравняется в скорости»:), а тут разгромит:)

только вот примеров кроме синтетических тестов, как т сам выразился никто не приводит.

Ну, а уж подобрать специальный тестовый пример, в котором современная JVM разгромит конкретный современный популярный C/C++ рантайм не так уж и нереально.

Ну так может быть что бы не быть голословным подберешь?

Указанный Вами тест, по-моему, не адекватен и вот почему. Он сравнивает самые быстрые реализации относительно быстрых вычислительно сложных алгоритмов. И тут, верояно, почти каждое слово важное....
А то что, Java проигрывает в синтетических тестах — так кому это на самом деле важно?

Это был не тест, а real world задача, причем далеко не первая подобная в моей практике.

Опять хотел написать краткий ответ, а вышла простыня. Извиняюсь перед всеми, кому этот оффтоп не интересен.
2crypto5
Да разве ж я где-то говорил, что Java — идеал на все случаи жизни? Нет, ей далеко до идеала. Даже тот же.Net просто из-за того, что выпущен позже, смог избежать некоторых ошибок и необдуманных решений (а некоторых не смог). И поскольку универсального хорошего языка, чтобы делать на нём и риалтайм ембедед системы и корпоративных монстров не видно, то судить о «хорошести» языка имеет смысл только в рамках его ниши и ещё по размерам этой самой ниши.
Когда я писал про «уж очень редкий частный случай» я имел в виду, что сохранение большого массива данных без какой-либо структуры и внутренних связей — это, по-моему, редкий частный случай. Общая задача «глубокой сериализации» — важная задача и над ней работают. А этот частный случай не достаточно важен, чтобы в Java оптимизировали именно его. При этом следует признать, что оптимизировать его в Java без существенного изменения основ языка, видимо, нереально.
Ну, а про память и тормоза что спорить? Есть в дизайне Java некоторые проблемы, которые не будут решены никогда (типа c2.com/cgi/wiki EveryObjectIsaMonitor, которая, кстати, и жрёт лишнее слово для каждого объекта), и которые будут решены очень вряд ли (отсутствие аналога C-структур), но всё же здесь есть и не малая часть от дурной славы прошлого (читай плохой реализации компиляторов и JVM). Многие проблемы уже решены, по крайней мере, для важных в реальной жизни ситуаций. Некоторые решаются сейчас. А некоторые, наверное, не будут решены никогда.
Например, сборщик мусора, ставший уже притчей во языцех. Правда ли что он так уж медленно работает? Плохо предсказуемо — да, и это минус. Но точно ли медленно? Большой не факт. Это определяется качеством менеджера памяти, а в его реализацию в JVM вложено немало усилий. Фанаты C/C++ часто забывают, что там тоже есть какой-то менеджер памяти и большой не факт, что он на практике лучше работает на больших объёмах данных. Более того, по ряду причин сейчас он часто работает хуже. Ну, а уж подобрать специальный тестовый пример, в котором современная JVM разгромит конкретный современный популярный C/C++ рантайм не так уж и нереально.
Идея: Выделяем кучу мелких объектов пока не забьём всю память для сегментации heap’а, потом освобождаем в случайном порядке некоторую часть типа 1/3, и дальше просим выделить нам память в виде больших непрерывных кусков. Думаю, для многих менеджеров памяти это будет не простой задачей, а шанс нарваться на ответ, что память кончилась — значительно выше. У JVM тут преимущество, например, в том, что оно может переносить объекты в памяти. Таким образом, сегментации свободной памяти может быть значительно ниже.
Правда ли что java медленная? Тоже не факт. Указанный Вами тест, по-моему, не адекватен и вот почему. Он сравнивает самые быстрые реализации относительно быстрых вычислительно сложных алгоритмов. И тут, верояно, почти каждое слово важное.
Во-первых, по-моему, значительно интереснее сравнивать средние реализации. Да, в C/C++ есть техники, недоступные java, позволяющие кое-что делать быстрее и иногда намного. Вопрос только в том, какая доля программистов смогут правильно использовать эти техники именно для оптимизации, а не для извращённого способа выстрелить себе в ногу? И сколько времени потребует такое вылизывание кода? По-моему, значительно более интересным было бы тестирование в таком духе: берём 1000 профессиональных программистов на Java и 1000 на C/C++. Даём им одинаковые задания и некоторый разумный лимит времени. И дальше сравниваем суммарное время работы всех решений на одном языке и на другом (+ ещё как-то нужно учесть, сколько из решавших не справились в отведенное время, и сколько решений будут падать или работать некорректно.)
Во-вторых, JVM может использовать то, что байт-код ещё нужно компилировать, как преимущество. Не знаю, делается ли это сейчас, но в принципе может пытаться смотреть на то, на каком CPU JVM работает и компилировать код под его конкретный набор инструкции со всеми расширениями. Кто, кроме гентушников и некоторых разработчиков 3D-шутеров, может позволить себе заняться оптимизацией такого рода в мире C/C++?

В-третьих, специфика решаемых задач, возможно, не позволяет java показать свою мощь. Например, как я слышал, JVM следит за статистикой выполнения программы и в некоторых случаях, основываясь на ней, умеет перегенерировать некоторые куски кода в более быстрые. Понятно, что на C/C++ такая джедайская техника не доступна в принципе. Или тот же сборщик мусора. Судя по всему, одним из плюсов использования сборщика является то, что объекты, выделенные близко по времени в коде, будут находиться близко в памяти, что повышает шансы на то, что они вместе попадут в кэш CPU, а это может оказаться критически важно, особенно в многопоточной среде. Только вот такие особенности проявляются на значительно больших объёмах данных, большем времени работы и, возможно, более многопоточной среде. Соответствует это специфике применения Java сегодня? По-моему вполне. Так что оптимизация ведётся, в общем-то, в верном направлении. А то что, Java проигрывает в синтетических тестах — так кому это на самом деле важно? Вам шашечки или ехать надо?

ну с этим точно никто спорить не будет. Сейчас придут джависты и скажут, что память в современном мире стоит копейки и поэтому не стоит ее экономить:) и соответственно ее во внимание принимать не следует:)

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

Ну и я удивлюсь если кто то будет доказывать что джава экономна по памяти. Помоему это самая жрущая память платформа.

ну с этим точно никто спорить не будет. Сейчас придут джависты и скажут, что память в современном мире стоит копейки и поэтому не стоит ее экономить:) и соответственно ее во внимание принимать не следует:)

Но даже ваш пример про массив объектов — уж очень редкий частный случай.

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

Ну, а про лишнюю память совсем смешно. В C++ метаданные вообще не хранятся, да? Т.е. где находится таблица виртуальных функции объекта код угадывает?

В моем случае мне нужно было хранить в обьекте тройку числовых филдов разных типов, то есть в С++ никакой таблицы виртуальных переходов не было бы. Поскольку данный масив был очень большим, у меня в памяти для джава помещалось значительно меньше обьектов (в раза два), и это все очень плохо сказывалось на производительности алгоритма. То есть решение конкретно этой проблемы заключаеться в том что бы все числовые значения держать в разных масивах, но это уже workaround вокруг недостатка языка.

Ну и я удивлюсь если кто то будет доказывать что джава экономна по памяти. Помоему это самая жрущая память платформа. Сравнение c с другими можно посмотреть например здесь: shootout.alioth.debian.org/u64q/java.php

Извиняюсь за разавитие офтопа, но не смог удержаться.

2eugene_n

Это не бага. Это фича.
И почему, если это фича, вдруг таки появилось ключевое слово restrict? А появилось оно, чтобы компилятор мог генерировать более оптимальный код. Компилятору труднее понять семантику, чем программисту. Понятно, что пример про многопоточность несколько надуманный. Просто это простой способ показать важность возможности/не возможности побочных эффектов при выполнении кода. Но знание того, что побочных эффектов нет, позволяет оптимизировать и однопоточный код. Простой пример приведен в en.wikipedia.org/wiki/Restrict
2crypto5
Я не спорю, что теоретически самый быстрый и компактный код можно написать на ассемблере конкретного процессора. У меня было два аргумента в пользу того, что высокий уровень абстракции не так уж и плохо:
1) Насколько реально, что обычный программист сделает низкоуровневый код лучше, чем сгенерирует современный умный компилятор из высокоуровнего кода того же программиста
2) Если согласится, что пункт 1 маловероятен, то возникает следующий вопрос. Что занчит написание менее абстрактного кода, в частности применение StringBuilder’а например? Это, по сути, проведение преждевременной оптимизации. Таким образом Вы лишаете компилятор шанса сделать его работу наилучшим образом. Более того, при этом часто запутывается семантика с точки зрения человека. Ведь как известно «premature optimization is the root of all evil».
Согласен, что есть случаи когда именно это конкретное место тормозит, и видно, что компилятор не достаточно умён, чтобы его улучшить. В этой ситуации имеет смысл оптимизировать именно это место. Заниматься же такой лабудой везде — вредить себе.
Вы одновременно ухудшаете читаемость кода и лишаете себя оптимизационного будущего. Если Вам очевидно, что компилятор генерирует плохой код в каком-то случае и этот случай не такой уж и редкий, вероятно в будущем компилятор станет умнее. Причём вероятно он станет не просто умнее, а умнее Вас и Вашей оптимизации, как уже было в указаном мной примере про StringBuffer. И уж совсем глупо делать в коде ту оптимизацию, которую компилятор уже умеет делать за программиста.
И конечно я согласен, что есть операции, которые трудно сделать хорошо на каком-то языке. Но даже ваш пример про массив объектов — уж очень редкий частный случай. Это значит Ваши объекты должны быть по сути структуры, а не объекты и вообще не содержать указателей. Или Вам придётся делать кучу хитростей чтобы убедиться, что Вы
а) сохранили всю требуемую память по всем указателям
б) восстановили всю память ровно по тем же адресам
ну или Вы умеете чинить все адреса на ходу, что реально, но тоже выглядит мрачно.

Ну, а про лишнюю память совсем смешно. В C++ метаданные вообще не хранятся, да? Т.е. где находится таблица виртуальных функции объекта код угадывает? Или когда программист выделеят массив в N байт, выделяется ровно N байт памяти, да? А потом когда выполняется

delete []p

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

Другой пример: компилятору C/C++ очень трудно было автоматически распараллелить почти любую работу по потокам.

Это не бага. Это фича. И эта фича состоит в том, что поведение программы определяется во время компиляции, Потому, что такой код можно ручками разбить на несколько потоков/процессоров, а наоборот — проблематично.

И ктстати очевидно что с конкатенацией тоже нужно смотреть на конкретные случаи, например:


String s = "";
for(int i = 0; i < n; i ++) {
s += i;
че то делаем
}

никакого StringBuilder-a или StringBuffer-a юзаться не будет.

Очевидно есть примеры в одну и другую стороны. Например недавно была задача, нужно было сохранять масив обьектов класса в файл и потом оттуда вытаскивать, на С++ понятно сохранил row memory в файл, потом вытащил сделал каст, в джава это все займет много больше операций. Ну и к тому же в джава любой обьект занимает + толи 8 то ли 12 байт уже не помню точно к размеру его полей.

Чем выше абстракция, тем ниже эффективность выполнение, мне кажется.

Не соглашусь. По-моему, сейчас среднестатистический компилятор/среда выполнения популярного языка в вопросах оптимизации значительно умнее среднестатистического же программиста. И эта разница со временем будет только расти! Более того, чем более высокий уровень абстракции используется, тем больше остаётся свободы компилятору для оптимизации.
Простой пример с тем же StringBuilder. До его появления сложение строк заменялось StringBuffer’ом. Потом поняли, что это плохо и сделали StringBuilder. Для тех, кто писал просто «+» нужно было просто перекомпилировать приложение с новым JDK. Те же кто явно использовал StringBuffer должны были менять это во всём коде, задумываясь каждый раз, нужна именно тут синхронизации или нет.
И если в дальнейшем в JVM/javac появятся другие, более тонкие оптимизации для массовой сливки строк, то старый-добрый «+», будет работать ещё лучше, а любителям StringBuilder’а придётся опять всё переделывать.

Другой пример: компилятору C/C++ очень трудно было автоматически распараллелить почти любую работу по потокам. Рассмотрим простую реализацию memcpy:


void my_ memcpy (void* dst, const void* src, size_t count) {
  for(; count; count--)
  {
    *(char*)dst = *(char*)src;
    dst++; src++;
  }
}

Можем ли мы для больших значений count для ускорения разбить работу на несколько потоков для утилизации нескольких ядер? А неизвестно! Потому что dst и src могут указывать на пересекающиеся области памяти. (Понятно, что это упрощенный пример, где проверку сделать легко, но эта проверка основывается на понимании семантики операции.) При копировании массивов на более высокоуровневых языках такой проблемы нету. Там легко проверить, одна и та же это ссылка или нет. Да в C сейчас можно использовать ключевое слово restrict. Но это опять-таки заставляет думать программиста, а не компилятор.

ИМХО единственное что реально угрожает java — это платформа.Net.

Чем выше абстракция, тем ниже эффективность выполнение, мне кажется.

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

По поводу скорости самой java — обратите внимание что byte code во время выполнения компилируется в машинный код

Тут всё дело в том КАК компилируется. См. выше, если тип указан явно, интерпретатору байткода нужно делать меньше телодвижений, соответственно скорость больше. Кстати, именно поэтому среднестатический паскалевский компилятор в вакууме, быстрее сишного — типизация строже.


Поэтому скорость выполнения Java программы вполне соизмерима со скоростью выполнения не оптимизированной C++ программы, написанной средней руки программером.
очень голословное утверждение. Не говоря уже о том, что сравнивать надо Ceteris paribus. ТОесть одинаковые условия.

При желании и на пхп хороший программсит может сделать быстрее, чем слабый программист на си.

Не думаю, т.к. имхо, код на Java будет быстрее из — за строгой типизации. Тут ведь как: меньше типизация — больше скорость разработки — меньше скорость выполнения кода.

Они там как раз и пытаются в 7-ую джава всунуть реализацию Dynamic Invocation: JSR 292, что должно упростить реализацию динамических языков, и ускорить вызовы методов в них.

В этом контесте — новый ЖВМ язык это проблема тогоже уровня что и изучить новый веб фреимворк.

Другое дело, что без нормальной ИДЕ все эти динамические языки годяться только чтобы маленькие быстро скриптики сочинять.

JVM — это Java virtual machine. Она выполняет java byte code. В это код можно скомпилировать программу с разных языков, например JRuby, Jython (python),...
Насчет зарплат Java программистов — они определяются спросом. Не думаю что спрос на Java разработки снизится со временем, для этого нет никаких причин, тк фактически это стандарт для корпоративных систем. Не говоря уже о том что есть куча legacy систем на ней, которые нуждаются в саппорте/развитии.
Насчет сравнения скорости выполнения программы на Java и программы на каком-либо языке который компилируется в байт код — тут нет никакой разницы, тк JVM имеет дело с byte code, а их чего он получен не имеет значения.

По поводу скорости самой java — обратите внимание что byte code во время выполнения компилируется в машинный код, плюс JVM выполняет кучу оптмизация при компиляции. Поэтому скорость выполнения Java программы вполне соизмерима со скоростью выполнения не оптимизированной C++ программы, написанной средней руки программером.

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

Вроде уже сто лет как. en.wikipedia.org/...i/JVM_languages

Это сулит поднятие з.п. java — программистов. Т.к. одну и ту — же работу за счёт новых Я.П. можно будет сделать быстрее, значит ещё большее количество народу захочет иметь java — программистов у себя в штате

Только для этих новых ЯП нужны программисты на этих новых ЯП. Java-программист не станет автоматически знатоком лиспа или питона от того, что этот лисп или питон будет работать на JVM.

Не думаю, т.к. имхо, код на Java будет быстрее из — за строгой типизации. Тут ведь как: меньше типизация — больше скорость разработки — меньше скорость выполнения кода. + Чует моё сердце, что расширения этих языков будут писаться на java

+1

А то я скорость выполнения никак с Java не связываю;)

Ну вот опять начинается. А с каким языком из перечисленных в вашем профайле вы связываете скорость? С интерпретаторами ПХП и Питона?;)


Не думаю, т.к. имхо, код на Java будет быстрее из — за строгой типизации. Тут ведь как: меньше типизация — больше скорость разработки — меньше скорость выполнения кода. + Чует моё сердце, что расширения этих языков будут писаться на java

А можно объяснить что такое скорость выполнения кода? А то я скорость выполнения никак с Java не связываю;) И не надо кричать про кривые руки программистов. Потому как если так кричать, то их прямых ни у кого не имеется, парадокс получается.

Когда выйдет 7 версия?

или все перейдут на с#?

Падение зарплат Java программистов?

Это сулит поднятие з.п. java — программистов. Т.к. одну и ту — же работу за счёт новых Я.П. можно будет сделать быстрее, значит ещё большее количество народу захочет иметь java — программистов у себя в штате

Вымирание java и заменой его более быстрым для написания языком?

Не думаю, т.к. имхо, код на Java будет быстрее из — за строгой типизации. Тут ведь как: меньше типизация — больше скорость разработки — меньше скорость выполнения кода. + Чует моё сердце, что расширения этих языков будут писаться на java

Java уйдёт? и перейдут на с#?

какой такой ряд?

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

Підписатись на коментарі