еще бы memory management был нормальный, цены б ей небыло...

В смысле нормальный? С указателями и подобным отстоем?!? Garbage Collection рулит!

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

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

По поводу Java. За что она она мне не нравится - что нужно явно указывать exceptions, к-рый может генерить моя функция. Что, компилер это сам просечь никак не может ? Нахрена тогда вообще нужен компилер, если не для автоматизации подобных рутинных операция ? Дальше, кто-нть сравнивал устойчивость к взлому прог, написанных на C & Java ? Десятки раз, IMHO Короче, нашли чего сравнивать, Java sux & must die

Даешь Це крест крест!!!!

Смешно. "Правильным" подбором конфигурации для тестирования много интересного добится можно...;) Вот например известный случай с тестами NT vs Linux - когда я посмотрел на конфигурацию все сразу стало понятно, они была оптимальна для NT и весьма неудачна для Linux. Про то что Linux якобы был неоптимизирован не надо - тесты были повторены после того как над Linux поколдовали спецы из RedHat и это ничего результаты принципиально не изменило - как он проигрывал, так и проиграл... Только результат стал слегка менее разгромным. А еслиб была взята другая конфигурация то результат был бы другим с точностью до наоборот. ;) Так и здесь - машина явно была оптимизированна под жабу и соответственно к реальной производительности эти тесты имеют мало отношения...

Такой фигни еще не слышал...

То ли автор страницы - полный ламер, то ли вешает лапшу на уши. В любом случае компилируемые языки О ОБЩЕМ СЛУЧАЕ быстрее интерпретируемых на порядки! И не надо про якобы супернавороченую виндовую Java VM... Эти тесты - полная лажа.

Пардон, но это не упрощения. Это СТРОГОСТЬ. Строгость языка не просто ограждает тебя от ошибок, но и позволяет не делать лишнюю работу. Да, я терпеть не могу Жабу, но не за строгость, а за излишнюю объектность. А вот модель распределения памяти и именования модулей в ней мне очень даже нравится. В моем любимом языке Objective Caml так же строгая типизация и встроенная сборка мусора - и это крайне слабо влияет на производительность, за то удобство дает немеряное. Да и вообще - попробуйте, господа, перечислить те задачи, которые вам наиболее часто встречаются, в которых критична производительность. А потом подумайте, насколько более критична защищенность от ошибок на уровне языка и скорость разработки.

Дык ведь честно признались - считали на вычислительных задачах. FFT и Жизня вообще к вопросам оптимизации слабо критичны...

Такой фигни еще не слышал...

Человече, Жаба давно уже не есть интерпретатор байткодов. Байткоды компилятся в нейтив непосредственно перед исполнением. А теперь давайте вспомним, как работает всеми нами горячо любимый GCC... Правильно - сначала компилит в коды некой весьма абстрактной машинки, и потом оптимизирует уже на этом уровне. Так что, по сути, технологии компиляции Жабы и сей маловато различаются...

по поводу указателей

> В смысле нормальный? С указателями и подобным отстоем?!? Garbage Collection рулит!

понимаешь, дело не в наличие/отсутствия указателей. Просто скажем в C++ все было четко - можно всегда гарантировать, что объект будет уничтожен в определенно месте, явно или неявно. В Java - нет. В Java нет такой удобной вещи, как автоматических переменных, а из-за сборщика мусора проблема утечек памяти встает в другом ракурсе. Кроме того, сборщик мусора довольно плохо справляется в условиях ограниченной памяти и программ, часто распределяющих/освобождающих память.

> Дальше, кто-нть сравнивал устойчивость к взлому прог, написанных на C & Java ? Десятки раз, IMHO Короче, нашли чего сравнивать, Java sux & must die

не совсем понятно, как из того, что Java устойчивее к взлому в десятки раз, чем C, сделан такой вывод :-)))

Года два назад пробовал работать с JDK 1.0.X. Проработал с этим пакетом всего один день. И не жалею что не стал тратить много времени. Возникли проблемы с тригонометрическими функциями. Делал тестовые вычисления с фунциями типа синус, косинус, тангенс. Возвращаемые значения от Пи/2, Пи/3, Пи/4 известны. Но решения получались совершенно другими. Особенно если аргумент был резульиаиом умножения двух чисел. Эта проблема проявлялась как на платформе Linux, так и на OS/2. Возможно я что-то делал не так, но работу с Java пришлось забросить.

to maxcom: Если уж на то пошло, то автоматические ПЕРЕМЕННЫЕ в Java есть, нет только Автоматических объектов. Что это дает? (Берет?). Простите за IMHO, но, уж лучше не знать точно, когда будет освобождена память, чем освободить ее вручную в то время когда на нее еще (почему-то) есть ссылки. Все равно, мало памяти Java-приложение занимать не может --(.

по поводу указателей

> Просто скажем в C++ все было четко - можно всегда гарантировать, что объект будет уничтожен в определенно месте, явно или неявно. В Java - нет.
С другой стороны, сборщик мусора гарантирует, что объект будет уничтожен, когда он больше не используется - на мой взгляд это гораздо важнее.
> ... а из-за сборщика мусора проблема утечек памяти встает в другом ракурсе. Кроме того, сборщик мусора довольно плохо справляется в условиях ограниченной памяти и программ, часто распределяющих/освобождающих память.
При наличии сборщика мусора проблема утечек памяти не должна вставать вообще. Или в Яве есть какие-то свои особенности? Я с ней делов не имел.
Насчет ограниченной памяти: существуют разные алгоритмы GC, некоторые из которых требуют весьма немного дополнительной памяти. Ктсати, частый malloc/realloc/free вряд-ли даст выигрыш в скорости по сравнению с хорошим сборщиком мусора.

про автоматические переменные

дело в том, что кроме чисто памяти объект может заблокировать системный ресурс, как например java.io.File или java.sql.Connection. Потом, если не сделать close, ресурс остается занят до тех пор, пока сборщику мусора не приспичит почистить память. Чтобы этого небыло, надо вопервых не забывать про close(), а во вторых всюду писать try {...} finally { close() }, что как минимум выглядит некрасиво, да и забыть про это легко. Толи в C++: автоматические переменные удаляются при любом при выходе из блока - лепота.

razvitie Java technologij

"Жаба давно уже не есть интерпретатор байткодов. Байткоды компилятся в нейтив непосредственно перед исполнением..." =>> Mozhesh dat' link(s) na chto-to pochitat' o podobnih tonkostjah i vobsche o razvitie podobnih technologij (zhelatel'no in Russian, no bydy rad i English)?

по поводу указателей

> При наличии сборщика мусора проблема утечек памяти не должна вставать вообще. Или в Яве есть какие-то
> свои особенности?
особенностей нет, просто иногда бывает тяжело найти, в какую коллекцию
и когда попал определенных указатель и почему он еще жив.

>> При наличии сборщика мусора проблема утечек памяти не должна вставать вообще. Или в Яве есть какие-то >> свои особенности? >особенностей нет, просто иногда бывает тяжело найти, в какую коллекцию >и когда попал определенных указатель и почему он еще жив. Вот это круто! Как же ты на С++ пишеь тогда? если не знаешь в каких коллекциях твой обьект? То есть сделал delete в одном месте, а в других местах (коллекциях которых ты не хочешь запоминать) пусть ссылка пальцем в небо указывает?

Suxx!! Must Die!! Каждый раз когда вижу такие слова - возникает ощущение что человек не владеет вопросом. Вы сами то, уважаемые C++ zealots пробовали повторить тесты из статьи? Я тоже был удивлен этой статьей - но попробовал повторить. Результаты отличаются но не намного.. Можно сказать что скорость Java и C++ сопоставима.

Е-мае.. Нашли что сравнивать: Java, язык для побрякушек в веб-страницах, и C язык для всего остального ;-) Имхо, "NT vs. Linux" номер два.

По поводу стойчивости к взлому - прогу на java взломать в десятки раз легче, чем прогу, написанную на C. Достаточно привести в пример jade - декомпилер .class файлов. Ещё есть вопросы ? Или приведите мне в пример реально работающий декомпилер C

> Нашли что сравнивать: Java, язык для побрякушек в веб-страницах, и C язык для всего остального ;-)
Ну да, если бы с апплетами можно было сделать что-то толковое, это бы уже обязательно сделали. Но Ява апплетами не ограничивается: JavaBeans, EJB, JSP тебе ничего не говорят?
> По поводу стойчивости к взлому - прогу на java взломать в десятки раз легче, чем прогу, написанную на C. Достаточно привести в пример ade - декомпилер .class файлов.
Ну если под взломом понимать reverse engineering то да. Однако термины buffer overflow и stack smash придумали не просто так. Грубо поиметь серверное ПО писанное на С обычно проще чем Явовское.

Не Jade, а Jad. Я думаю, имеется в виду устойчивость к exploits like buffer overflows. Сама Java как язык застрахован от этого, но не забывайте, что JVM писана на том же C, причем писана мягко говоря ахово, что подтверждается уже трехлетним опытом разработки под MD, MacOS, Solaris и Linux на Java. Кроме того, в конце концов начинают задалбывать явные костыли, а именно, отсутствие множественного наследования, generic классов и функций, кривость базовой библиотеки и Swingа, тот факт, что Write Once Run Everywhere является не более, чем рекламным трюком. От некоторых кривостей спасает Kawa, Kiev, AspectJ или GJ, однако плохие JVMs - это уже диагноз. :))) Корки Blackdown's, Sun's и IBM's JVM всех версий под Линуксом стали уже притчей во языцах. Я думаю, что было бы логичнее противопоставить этой propriental кстати технологии открытую и более мощную GUILE. Ибо и Scheme - это на порядки более качественный язык чем жаба, да и не придется зависить от коммерческой компании, M$ N2, а может и один ;)

> Ибо и Scheme - это на порядки более качественный язык чем жаба, да и не придется зависить от коммерческой компании, M$ N2, а может и один ;)
Главное достоинство Явы - С++ alike syntax, позволяющий легко покорить сердца миллионов программистов-сишников. Я и сам предпочел бы видеть guile вместо java, но увы: the worse is better.
Кстати, к созданию Java приложил руку Guy L. Steele, автор Common Lisp. Некоторые приписывают ему наличие в Яве GC и анонимных классов.

Видимо, так и придется на Kawa да на Skij писать :)))

Вот и получилась она такая же громоздкая как CL :)) Вот если бы Sussman - может дело было бы

Не надо ля-ля. Если в Internet Java-апплеты не очень популярны,
то в Intranet наооборот. Почему?
1. Скорость передачи данных в локальной сети достаточно большая
чтобы быстро грузить апплеты.
2. Самое важное - на всех машинах можно поставить один и тот же
броузер+Java Plug-In и проблем с несовместимостью нету. Делаеш
апплеты без головной боли.

И еще - у Java мощный API, который берет всю тяжелую работу прог-
раммиста на себя. Поэтому код получается краткий, эелегантный и
интуитивно понятный. Что из этого вытекает - короткий срок напи-
сания приложений по сравнению с другими языками.

P.S. кстати, где-то читал что Ada предлагает свои средства разра-
ботки апплетов которые не хуже Java-апплетов

Блин, мужик, ты чудак или претворяешься. На кой черт в интранете апплеты,когда и приложения через CORBA или ILU могут прекрасно общаться. ILU кстати имеет Scheme binding, то же верно и для ORBit

to anonymous:
А на тот черт, наверное, что о переносимости люди думают.
Что такое ILU не слышал, но об ORBit нельзя говорить "переносимо".
Пойди напиши на C переносимый софт ... Думаю, что на
Java попроще будет. А во-вторых, переносимость самого ORBit'a ...

Всему свое место, CORBA тоже вещь хорошая, но для других целей.

На счет ILU сходи на сайт XEROX PARC Лично я гонял его на Соляре, Линухе, фрюшке и мастдайке - рулит на ура. И все равно не ясн, нафига жаба в интранете. Кроме того, было ясно сформировано условие, софт в интранете контролируется нами, т.о. берется какой-нибудь ORBit или MICO - и вперед - везде рулит.Да, ORBit тож сам по себе достаточно неплохо переносим, по-крайней мере, одну из ранних его версий мне за неделю удалось заставить работать даже на маке. На счет переносимости жабы - да не смешите мои пятки :))) С AWT полнейшая беда, о бездарном java.awt.FontMetrics я и не говорю, то, что на некорых "оптимизированных" JVM вместо NullPointerException кидается горячо любимый SIGSEGV, на ряде JVM картинки и музыка полученная с помошью getImage и getAudioClip остаются в памяти навечно, секьюрити иногда доходит до маразма, в RMI инвокация метода на localhostе занимает до 1 секунды... Список притензий можно продолжать и продолжать

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

Видишь магические буковки jsp ? ;)

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

Скорее даже не сама жаба, а мощные кодописаки :))) проекта GnuJSP :)

> Вот и получилась она такая же громоздкая как CL :))
Он не громоздок, а могуч :)
> И еще - у Java мощный API, который берет всю тяжелую работу прог-
> раммиста на себя. Поэтому код получается краткий, эелегантный и
> интуитивно понятный. Что из этого вытекает - короткий срок напи-
> сания приложений по сравнению с другими языками.
Вот ради Бога, не надо. С этим лучше на comp.lang.java.advocacy.
Каждый новый язык претендует быть "облегчающим", "интуитивно понятным", "более мощным" и т.п. Моду на такую пургу ввел еще Н. Вирт (при всем моем к нему уважении) со своим Паскалем и структурным программированием. Но бредятину про API, "берущий работу программиста на себя" я слышу впервые. Последняя же фраза вообще некорретна: приложения бывают разные, и языки разные. Попробуй что-нибудь кроме разработки GUI и клея к БД на Pascal/C++/Java, а потом сравнивай.

Точно, точно, ибо только функциональные языки могут быть интуитивно понятными ;))

На счет мощного API: Ни один API , во-первых, не заменитголову, а, во-вторых, не вылечит кривость языка. Это же не C++, где можно сымитировать почти любой стиль программирования. А кривостей в Java как языке предостаточно: 1. Нет поддержки generic классов - это уже диагноз, ибо без них невозможно написание typesafe и эффективных контейнеров 2. Нет множественного наследования, что подчас приводит к такому уродливому дизайну, что аш тошно становится 3. Статическая типизация (reflection - это не решение) делает жабу неприемлимой для создания гуя. 4. Анонимные классы - это конечно хорошо, однако они сильно раздувают размеры программ/апплетов, что иногда неприемлимо, кроме того, даже им далеко до горячо любимого (lambda () ... ) 5. Довольно убогая синхронизация делает написание Dead Lockов особенно простым делом :))) На счет столь разрекламированного API: 1. java.awt.Vector, один из самых широко используемых контейнеров, реализован до безобразия неэффективно, даже java.awt.Container не использует его для хранения детей, хотя это было бы логично 2. AWT, мягко говоря, работает несколько по разному на разных платформах 3. AWT не мультитредово, т.к. добавление/удаление одного компонента приводит к блокировке ВСЕХ AWT компонент (see sources) 4. SWING и Java2D притормаживают, причем явно из-за кривости ручек программеров от SUN 5. Нарисовать в java.awt.Image можно только если эта картинка получена от проинициализировавшегося Component by Component.getImage(). Иначе, в нарушение interface spec, Image.getGraphics() даст null. Т.о. отсутствует возможность создания offscreen images на graphics-less серверах. 6. Метрик, возвращаемых java.awt.FontMetrics явно недостаточно. Это так, список Why Java is SUXXX v.0.0.0