Главная страница
Top.Mail.Ru    Яндекс.Метрика
Текущий архив: 2008.05.11;
Скачать: CL | DM;

Вниз

Надежность JAVA-приложения   Найти похожие ветки 

 
@!!ex ©   (2008-03-22 17:05) [0]

Конторе есть необходимость разработать ряд крос-платформенных серверов для расчетов.
Выбор стоит между С/C++(крос-платформенность на уровне исходного кода) и JAVA. Сразу оговорюсь, именно между ними,
другие языки не рассматриваются в силу целого ряда причин (не буду их приводить, к вопросу это не относится).
Сервера должны работать в режиме 24/7. Возникает вопрос, насколько надежно работает JAVA(точнее JVM).
Есть ли опыт такой работы (положительны/отрицательный).
Важно: я точно сказать не могу, не я решаю, но по опыту могу сказать, что речь идет о ПО стоимостью СОТНИ тысяч $. Цена простоя сервера измеряеться в миллионах $ в сутки. Т.е. надежность приложения на уровне, "у меня повисла прога, я ее перегрузил и все" это равноценно полному отсутствию надежности. На С/С++ решения есть (базы данных, apache и т.д.). На JAVA я подобных решений не видел.
Задавал вопрос на Delphikingdom, все свелось к JAVA рулит, но лучше FPC, мои аргументы не услышали.
Задавал вопрос на sql.ru, все свелось к JAVA рулит, а я ничего не понимаю в программировании, конкретных примеров на JAVA не привели.
Возможно Вы поставите точку в выборе? :)


 
Reindeer Moss Eater ©   (2008-03-22 17:15) [1]

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

Первый вариант.


 
Поп Гапон   (2008-03-22 17:16) [2]


>
> @!!ex ©   (22.03.08 17:05)


Java нужно уметь готвить, так как если не следовать рекомендациям(фичам) то тормоза будут жуткие.

Из недостатков
1. Нет определенного на уровне языка виртуального деструктора как в Delphi.
2. Мусорщик запускается только когда нехватка памяти(но можно вызвать самому). Так что может случится на машинах с 4-16 Гб памяти что закончатся GDI ресурсы или объекты ядра быстрее чем память.
3. если Java сервер под винду, то нельзя регулировать размер стека(он всегда мах 1 Мб), под *nix, Linux можно.
4. Все есть объект, так что работа со строками медленная, но есть стрингбилдеры, которые решают эту проблему.
5. Хоть сетевые сервисы работают довольно шустро, Гуи... вроде в Java6 наконец-то тормоза убрали. Но это более к преимуществам для вас, так как у вас сервера.

Преимущества:
1. Большая библиотека чего угодно, как на делфи компонент, но больше и кросплатформенно.
2. минимальные танцы с бубном при переносе на другую платформу аналогичную по мощности системы(совсем без них не выйдет).
3. Совмещение работы с программой как со скриптом(рефлекшены, обращение к методам и полям по имени и пр) так и компилируемым языком.
4. jit компиляция, тоесть оптимизация кода в онлайне на запускаемый процессор самим компилятором java байт-кода в нативный (часто подглючивает и генерирует тормозной код).

Вроде все.


 
ferr   (2008-03-22 17:19) [3]

java рулит так как jvm стабильна это одын, два это что код на жаве будет содержать меньшее количество ошибок, в силу специфики, так что она в общем-то рулИт. за fpc отрывать конечности, дрянь редкостная..


 
DrPass ©   (2008-03-22 17:22) [4]


> Т.е. надежность приложения на уровне, "у меня повисла прога,
>  я ее перегрузил и все" это равноценно полному отсутствию
> надежности. На С/С++ решения есть (базы данных, apache и
> т.д.). На JAVA я подобных решений не видел.

Java, в отличие от остальных платформ, даст тебе огромное преимущество - сервер приложений. Который будет рулить транзакциями, пулами соединений с СУБД, кешированием программных модулей, обеспечит кластеризацию и как следствие - отказоустойчивость и балансировку нагрузки между несколькими узлами.
Все это УЖЕ есть в J2EE. Бери (купи) и используй. Для С++ таких решений (по крайней мере, "массовых")ты не найдешь.
Другое дело, что проект действительно должен стоить этой сложной и мощной платформы.


 
Игорь Шевченко ©   (2008-03-22 17:37) [5]

Я бы не стал выбирать Java для 24/7. Тому есть примеры - Оракловский сервер приложений, который достаточно надежный, но...


 
@!!ex ©   (2008-03-22 18:01) [6]

2Reindeer Moss Eater:
Крос-платформенность нужна, т.к. у разных заказчиков разные платформы (Sun, HP, Win, Linux, IBM). Нужно снизить цену портирования и ошибки портирования.
2Поп Гапон:
1) проблема памяти это важно. Спасибо.
2) библиотке не нужна (чисто работа с БД+расчеты(в паралельных потоках)+прокача данных по сети (свой протокол на базе TCP ничего сверхестественного))
2ferr:
Если что-то случиться с JVM у заказчика, что мы будем делать? Sun не осуществляет поддержку JVM в режиме 24/7.
А то что они планируют(когда еще будет), будет стоить огромных денег.
2DrPass:
Нам не нужен сервер приложений (внутрений сервер расчетов, никто с ним работать не будет). Кластеризация нам не подходит по раду причин (например скорость: сервер ежесекундно должен через себя прокачивать около 3000 записей в один поток(2 потока 6000 и т.д.), у кластера сразу возникнет проблема синхронизации общих данных).
2Игорь: а конкретнее? Есть опыт? Можешь поделиться (без деталей)?


 
Игорь Шевченко ©   (2008-03-22 18:15) [7]

А что конкретней, набираешь в гугле oracle application server bugs


 
Simpson   (2008-03-22 18:17) [8]

Поп Гапон   (22.03.08 17:16) [2]
err   (22.03.08 17:19) [3]
Игорь Шевченко ©   (22.03.08 17:37) [5]
Это у них Ахилессова пята такая, дело в том что Java сколько бы не говорили не занимается сбором мусора, этим должен озаботиться программист, то есть программер ДОЛЖЕН ЯВНО УКАЗЫВАТЬ, что надо удалить, сама Java фиг что удалит если есть ссылки на интерфейс. В запутанных(сложных) интерфейсах ссылки есть всегда, результат System.gc() их не удалит из пямяти.

но не будем голословными, поcмоторим что даст http://www.yourkit.com/ про работу вашего приклада?/*не реклама сам пользуюсь*/
Дык вот оно как оказывается, надо следить за обеъктами и удалять их, иначе срач в памяти и захлебываемся через Х часов.
Это про память, про мультипратформенность, все функции работы с OS(открытие файла например) реализованны через native функции, не секрет что работа в разных OS по разному происходит работа с файлом так что отличая есть и с этим придется бороться...


 
Petr V. Abramov ©   (2008-03-22 18:18) [9]


> Игорь Шевченко ©   (22.03.08 18:15) [7]

тут специфика, этим людям нельзя доверять писать ничего, кроме dbms :).


 
Игорь Шевченко ©   (2008-03-22 18:19) [10]

Petr V. Abramov ©   (22.03.08 18:18) [9]

Инсталлятор ихний на Java написанный вполне себе работает. Да и прочие тулзы. Но не в режиме 24/7.


 
ferr   (2008-03-22 18:22) [11]

> Это у них Ахилессова пята такая, дело в том что Java сколько
> бы не говорили не занимается сбором мусора, этим должен
> озаботиться программист, то есть программер ДОЛЖЕН ЯВНО
> УКАЗЫВАТЬ, что надо удалить, сама Java фиг что удалит если
> есть ссылки на интерфейс. В запутанных(сложных) интерфейсах
> ссылки есть всегда, результат System.gc() их не удалит из
> пямяти.

Вот Вы искренне считаете что умнее сановцев да? Ну я рад за Вас. Там всё открыто, правьте.


 
Petr V. Abramov ©   (2008-03-22 18:25) [12]


> Игорь Шевченко ©   (22.03.08 18:19) [10]

иногда. чего стОит история с неработой 8-шного на P-IV без спецтанцев.
утилиты типа netca и dbca - да, за 10 лет отладили утилитки из 10 экранов, но по мне они не образец удобства.


 
Simpson   (2008-03-22 18:29) [13]

ferr   (22.03.08 18:22) [11]
Дык нет не умнее, просто меня многое не устраивает, я не понимаю что делает в SDK переменная Virginity == девственность, почему никогда не удаляются из памяти сложные обьекты(перекрестные ссылки),почему в Swing реализация обработки событий происходит через 3 класса?

Почему???

Кстати, с памятью работу более менее решил, итак забываем напрочь что говорит SUN, любой обьект должен быть по заверщению уничтожен следующим образом:
object = null;
Иначе строки, объекты базы, да что угодно будет вечно торчать в памяти.


 
Simpson   (2008-03-22 18:35) [14]

ferr   (22.03.08 18:22) [11]
Ответь хоть на один вопрос защитник, зачем это было зделано?


 
Mystic ©   (2008-03-22 18:43) [15]

А какой у тебя опыт в Java, C++?

Я бы предпочел все-таки C++. Главным образом потому, что тут все в моих руках, я четко представляю, какие проблемы могут случится и как их решать (утечки памяти, AV, уязвимости, ...). В Java я бы не полез ввиду того, что (1) слишком аскетичный язык, на мой взгляд (2) нет достаточно опыта. Я не верю, что Java это панацея от всех бед. Проблемы обязательно будут (см. [2]), при этом зачастую характер проблем такой, что проявляться они могут далеко не сразу. А это очень неприятно для 24/7.


 
Simpson   (2008-03-22 19:36) [16]

@!!ex ©   (22.03.08 17:05)
Мое резюме(мой опыт 2 програмки 24/7(сервис, прога по закачке) зделано мною) надежность Java миф всю надежность придется тебе делать самому, иначе все упадет и не понятно почему.


 
DVM ©   (2008-03-22 19:59) [17]

У меня почти все проекты из расчета 24/7, и между Java и С я выбрал бы С. Причины описаны в [15]


 
31512   (2008-03-22 20:02) [18]

Мдяя. У нас Oracle падает аккуратненько раз в полгода. Первые 2 раза это вызвало панику с потерей данных. Потом научились. Остальные 6 раз уже просто небольшими беспокойствами отделались.


 
Petr V. Abramov ©   (2008-03-22 20:15) [19]


> 31512   (22.03.08 20:02) [18]

причину падения высянить не пробовали?
:)


 
Simpson   (2008-03-22 20:18) [20]

Petr V. Abramov ©   (22.03.08 20:15) [19]
Не стандартно мыслиш, в java принято на падение перезапуск ставить))


 
31512   (2008-03-22 20:20) [21]


> Petr V. Abramov ©   (22.03.08 20:15) [19]

Админ говорил, но у меня это со временем забылось. :-( В результате он лечит это за 15 минут. Всё зависит от того сколько будет дамп БД всасываться. Могу и ошибиться, но как раз там Жаба где-то дохнет.


 
Simpson   (2008-03-22 20:34) [22]

31512   (22.03.08 20:20) [21]
Жаба там дохнет от того что не вычищает после себя, все это накапливается и взрывается. Эта трабла еще с jdk 1.3 качует независимо от версий. Проверь на утечки и все станет на свои места.


 
31512   (2008-03-22 20:45) [23]


> Simpson   (22.03.08 20:34) [22]

Я вот теперь из принципа поинтерисуюсь у админа, чего он там накопал в качестве причины. :-))) Спасибо за наводочку. Признаться с Жабой я не имел дела и про такие проблемы с памятью слышу впервые. Хотя в одном из разговоров давным-давно эта тема затрагивалась. Говорили, что если объект А ссылается на объект Б, а Б на А, то сборщик мусора не может разрешить такую взаимную ссылку и объекты остаются в памяти до морковки на заговенье.


 
Автор вопроса   (2008-03-22 20:46) [24]

[с чужого компа]
Опыт есть: на JAVA писал аплеты (изучал ее) лет 8 назад. Все.
На С/С++ писал много, ряд сервисов в режиме 24/7 под разные платформы (крос-платформенный код). P.S. Это не так сложно, если ПО не взаимодействует с пользователем (различные сервера (демоны в *nix)).
Сейчас выступаю не как программист, а как архитектор новой системы. Я ее сам писать не буду, для этого есть программисты. Мне надо для себя понять, что лучше и почему. У них опыт работы как в JAVA так и в C/C++ есть но не фундаментальный. И они все как один за JAVA. Я их понимаю:
1) не надо изучать второй язык (JAVA у нас полюбому будет, как раз для клиентских приложений)
2) JAVA сейчас очень популярна. Они тем самым себе планку повышают, т.е. улучшают перспективы.
Но сам склоняюсь в сторону С/С++. Хотя бы по тому, что:
1) Есть ряд приложений, которые не работают толком на JAVA (HP IUM, Oracle application server), хотя компании-авторы могут себе позволить любых программистов. Вывод: не в программистах дело.
2) Отсутствие поддержки JVM, со стороны Sun и поставщиков железа (HP, IBM и т.д.). Если что-то произойдет с JVM у заказчика, что делать? К кому обращаться? Сколько времени уйдет на восстановление? На C/C++ проблема с компилятором может решаться очень долго, это наша внутренняя проблема. Заказчик о ней не узнает. Ему уйдет протестированный и рабочий код.
3) Ресурсоемкость JAVA. Был опыт: при простой замене парсера с perl на JAVA, требования к ресурсам возросли в 10(десять)!!! раз (CPU+память).


 
31512   (2008-03-22 20:55) [25]


> Автор вопроса   (22.03.08 20:46) [24]


> 2) JAVA сейчас очень популярна. Они тем самым себе планку
> повышают, т.е. улучшают перспективы.

Вот уж совсем не довод. Мало ли что сейчас популярно. Речь идёт о промышленной надёжности! Получается куда крестьяне туда и обезьяне?


 
@!!ex ©   (2008-03-22 20:59) [26]

> [24] Автор вопроса   (22.03.08 20:46)

Кстати, Автор вопроса - не я.
Просто с моего компа писали.


 
deneb   (2008-03-22 21:20) [27]


> 1) Есть ряд приложений, которые не работают толком на JAVA
> (HP IUM, Oracle application server), хотя компании-авторы
> могут себе позволить любых программистов. Вывод: не в программистах
> дело.


Дело в кошках (и рецепте приготовления).


> 2) Отсутствие поддержки JVM, со стороны Sun и поставщиков
> железа (HP, IBM и т.д.). Если что-то произойдет с JVM у
> заказчика, что делать? К кому обращаться? Сколько времени
> уйдет на восстановление? На C/C++ проблема с компилятором
> может решаться очень долго, это наша внутренняя проблема.
>  Заказчик о ней не узнает. Ему уйдет протестированный и
> рабочий код.


Очень надуманная проблема (лисичка приходит в обоих случаях).


> 3) Ресурсоемкость JAVA. Был опыт: при простой замене парсера
> с perl на JAVA, требования к ресурсам возросли в 10(десять)!
> !! раз (CPU+память).


В IBM на это отвечают: "If you want to eat hippopotamus, you"ve got to pay the freight."

Стоит обратить внимание еще на некоторые аспекты - сроки и квалификация разработчиков.
Если этим будет заниматься уважаемый @!!ex, то стоит выбрать Java, так как язык весьма незамысловат и обладает исчерпывающей библиотекой (об application серверах тут так же говорили, возможность синхронизации между нодами кластера есть, посмотрите как это реализовано в quartz).
Если вы можете позволить себе пожертвовать сроками и качеством, то C++ - ваш выбор.


 
Mystic ©   (2008-03-22 21:22) [28]

Тут надо еще помнить, что C++ язык острый как бритва, и при неумелом использовании может стать опасным. Ну и кроме того, если писать на C++ в функциональном стиле а-ля boost или а-ля Александреску, то с непривычки можно очень быстро утонуть в архитектуре. Далее, после долгих лет работы с managed языками придется восстанавливать (или приобретать) некоторые навыки программирования с нативным кодом (AV, memory leaks, низкоуровневая отладка, иногда даже ассемблер), потому как на Java быстро отвыкаешь об этом заботится.

Так что если бы я не принимал участия в разработке, то ориентировался на опыт программистов. Если у них большой опыт в Java и слабый опыт в C/C++, то я бы или искал новых людей или пришлось бы остановится на Java. Java хороша тем, что не требует большой скурпулезности в работе. Но при разработке 24/7 скурпулезности таки нужна, так что в этом случае я бы (1) тщательно изучил все возможные слабые места, возможности утечек (2) провел бы тесты по этим слабым местам [хотя на разных платформах Java может себя вести по разному] (3) на семинарах бы обсудил результаты (4) ввел стандарты кодирования с учетом результатов проверок (5) ввел бы обязательный code review.


 
Ломброзо (не с работы)   (2008-03-22 23:45) [29]

половина ветки - глупые измышления. во-первых, существут несколько реализаций jvm. чем дороже, тем устойчивей. во-вторых, проблема освобождения ресурсов давно решена, причем схожим образом и для java, и для с#. гуй в swing был, есть и будет тормозить, но к счастью,   существуют swt  и прочие легковесные оконные фреймворки. кроссплатформеность - вовсе не миф, и проект eclipse тому доказательство.


 
Reindeer Moss Eater ©   (2008-03-22 23:52) [30]

кроссплатформеность - вовсе не миф, и проект eclipse тому доказательство.

а еще есть джимм для нокии и джимм для сименса. и много других джимов для других телефонов.
а еще есть циско кол манаджер, который работает на jvm только определенного вендора.
а еще ....

не, не миф....


 
Petr V. Abramov ©   (2008-03-23 01:22) [31]


> 31512   (22.03.08 20:20) [21]

> Всё зависит от того сколько будет дамп БД всасываться.

> Админ говорил,

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


 
Petr V. Abramov ©   (2008-03-23 01:26) [32]


> Ломброзо (не с работы)   (22.03.08 23:45) [29]
> существут несколько реализаций jvm. чем дороже, тем устойчивей.

java - свободная, бесплатная, халявная технология, которая со временем приведет к торжеству свободного софта....


 
Автор вопроса   (2008-03-23 09:12) [33]


> Ломброзо (не с работы)   (22.03.08 23:45) [29]
> половина ветки - глупые измышления. во-первых, существут
> несколько реализаций jvm. чем дороже, тем устойчивей

Дай ссылку на платную, крос-платформенную  JVM, с поддержкой.
Я пока не видел платной JVM. На мой запрос, Sun официально ответил, что они пока такой поддержки не обеспечивают.


 
Alex Konshin ©   (2008-03-24 10:32) [34]


> Игорь Шевченко ©   (22.03.08 18:19) [10]
> Petr V. Abramov ©   (22.03.08 18:18) [9] Инсталлятор ихний
> на Java написанный вполне себе работает. Да и прочие тулзы.
>  Но не в режиме 24/7.

Я согласен с Петром. Писать на Java они не умеют. Видел я их произведения...
На Java нужно уметь писать, как и на любом другом языке.
Хотя потенциально серверные приложения на Java более надёжны.


 
Игорь Шевченко ©   (2008-03-24 10:34) [35]

Alex Konshin ©   (24.03.08 10:32) [34]

Отсюда вывод - не стоит применять Java для таких приложений (24/7) :)


 
Reindeer Moss Eater ©   (2008-03-24 10:42) [36]

Важно: я точно сказать не могу, не я решаю, но по опыту могу сказать, что речь идет о ПО стоимостью СОТНИ тысяч $.

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


 
Alex Konshin ©   (2008-03-24 10:45) [37]

> Автор вопроса   (23.03.08 09:12) [33]
>На мой запрос, Sun официально ответил, что они пока такой поддержки не обеспечивают.

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

Я работаю в фирме, один из продуктов которой как раз и есть сервер на Java, работающий на многих платформах 24/7. Заказчики серьёзные - Boeing, NASA, Airbus, Toyota,...


 
Alex Konshin ©   (2008-03-24 11:00) [38]


> Игорь Шевченко ©   (24.03.08 10:34) [35]
> Alex Konshin ©   (24.03.08 10:32) [34] Отсюда вывод - не
> стоит применять Java для таких приложений (24/7) :)

Не согласен.
При том же уровне программиста на C/С++ приложение вообще работать не будет. На Java скорее всего будет, но медленно. А если нужно быстро и надёжно, то нужно и программистов соответствующих.
На Java просто сделать самовосстанавливающийся сервер. А на C/C++ почти любая ошибка фатальна. То есть, для 24/7 Java намного более предпочтительна с этой точки зрения.

А насчёт производительности... Ты посмотри с такой стороны: насколько надёжно ты сможешь реализовать многопоточность с сервере на C/C++ и, главное, проследить, что все твои программисты будут так же аккуратны?
А ведь в современных условиях сервер просто обязан работать во многопоточной среде. Иначе все теоретические возможности оптимизации в C/C++ с лихвой покроются легкостью распараллеливания на Java. Да и не такая она уж и медленная, нужно просто уметь писать. Ситуация с Java примерно такая же, как и с Delphi: легкость языка порождает наплыв дилетантов, и их творения и создают имидж тормознутости.


 
Игорь Шевченко ©   (2008-03-24 11:10) [39]

Alex Konshin ©   (24.03.08 11:00) [38]

Когда все упирается в квалификацию программиста, тем более, задающего вопрос на форуме - "а что бы мне такое выбрать для написания сервера 24/7", то ответ вообще очевиден.


 
Alex Konshin ©   (2008-03-24 11:36) [40]


> Игорь Шевченко ©   (24.03.08 11:10) [39]
> Alex Konshin ©   (24.03.08 11:00) [38] Когда все упирается
> в квалификацию программиста, тем более, задающего вопрос
> на форуме - "а что бы мне такое выбрать для написания сервера
> 24/7", то ответ вообще очевиден.

Для серверов ответ, на мой взгляд, действительно очевиден. Я правда не совсем уверен, что мы очевидим одно и то же.

А в конкретном случае нужно смотреть более детально на саму задачу. Очень маловероятно, что C/C++ будет предпочтителен, но всё же случаи разные бывают.

Кстати, опять-таки по работе в фирме... У нас практически все приложения многоплатформенные, но это не значит, что везде используется Java. Есть много продуктов, написанных C/C++. Так что я непонаслышке знаком с вопросом выбора инструмента. Я специализируюсь на Java, хотя и умею C/C++ (как и многое другое). Но я рекомендую Java вовсе не поэтому, а потому, что хорошо знаком с достоинствами и недостатками обоих подходов.

В качестве ещё одного довода приведу ещё один: отладку и тестирование. На Java это будет намного проще и дешевле хотя бы потому, что зависимость от платформы меньше. Просто представьте себе объёмы тестирования сразу на многих платформах. Не забывайте ещё о 32-bit и 64-bit (на C/C++ это будет ещё одна тема для развлечений). В случае Java можно уменьшить количество платформ без существенного ухудшения качества тестирования. Обычно это сводится к паре-тройке платформ типа Windows 2003/XP (32/64 bit) и какой-нибудь юних типа Linux x86 64-bit, AIX, HPUX или Sun Solaris. Естественно, перед релизом нужно будет всё-равно тестировать все платформы, но хоть не нужно это делать с каждым билдом.


 
Alex Konshin ©   (2008-03-24 12:08) [41]

Ещё один довод: компиляция и сборка под все поддерживаемые платформы. Вы представьте, какую ферму серверов вам придётся иметь в хозяйстве только для того, чтобы строить приложение под все платформы. Может вы надеетесь на кросскомпиляцию в GCC? Я бы не стал на неё забиваться в таком серьёзном проекте, как вы его описываете. Лишние проблемы. Опять-таки я об этом знаю по реальному опыту работы в фирме. Один из проектов моей группы как раз на C/C++ и для него сборка довольно нетривиальна из-за необходимости компилиции на нескольких компьютерах под разными платформами. Конечно, у нас это автоматизировано, но повозиться пришлось немало. Кстати, а инсталятор для этого продукта всё равно на Java :).


 
Игорь Шевченко ©   (2008-03-24 12:31) [42]

Alex Konshin ©   (24.03.08 12:08) [41]

Я на Java так активно, как ты не работаю, более того, не работаю совсем, потому привел пример того, чего знаю. Исходя из того, что в Oracle тоже не очень дураки работают :)


 
31512   (2008-03-24 12:51) [43]


> Alex Konshin ©


> Игорь Шевченко ©

Господа. Внимательно наблюдая за дискуссией, возникшей тут, у меня назрел вопрос: исходя из требования надёжности системы класса 24/7 (в том числе, учитывая что убытки в результате сбоя могут быть ощутимыми),   вы предпочли бы нативное решение, указав заказчику "используй эту систему" (разумеется предварительно убедившись в надёжности самой системы) или же применили бы кроссплатформенное (тут ваш выбор) решение? И почему?


 
Alex Konshin ©   (2008-03-24 12:55) [44]

Зависит от требований заказчика. Под заказчика типа Boeing можно сделать всё, что пожелают.


 
Alex Konshin ©   (2008-03-24 12:57) [45]


> Игорь Шевченко ©   (24.03.08 12:31) [42]
> Alex Konshin ©   (24.03.08 12:08) [41] Я на Java так активно,
>  как ты не работаю, более того, не работаю совсем, потому
> привел пример того, чего знаю. Исходя из того, что в Oracle
> тоже не очень дураки работают :)

Откуда такое убеждение? Дураки работают везде!
И у нас тоже работают.


 
@!!ex ©   (2008-03-24 12:57) [46]

> [43] 31512   (24.03.08 12:51)

Я вообще не в теме, но насколько мне известное, софт под платформу(дело не только в ОС, но и в самом оборудовании) покупают, а не наоборот.


 
31512   (2008-03-24 13:00) [47]


> Alex Konshin ©   (24.03.08 12:55) [44]

Иногда заказчик говорит: "Что вы можете нам предложить?". Т.е. я хотел бы узнать ответ в случае, если бы выбор прогаммно-аппаратной части зависел от вас.


 
31512   (2008-03-24 13:08) [48]


> @!!ex ©   (24.03.08 12:57) [46]

Покупают - да. А вот разрабатывают? Т.е. я хочу сказать, что в большинстве случаев заказчик предподчёт съэкономить.
Вариант первый: мы хотим такой-то софт под платформу Грюндик.
Вариант второй: мы хотим такой-то софт но с платформой не определились может вы подскажете?


 
Игорь Шевченко ©   (2008-03-24 13:10) [49]


> Откуда такое убеждение?


"По плодам их узнаете их" (Матф., VII, 20)


 
Alex Konshin ©   (2008-03-24 13:12) [50]

Вариант третий и правильный: маркетолог изучает рынок и даёт список платформ и количество потенциальных клиентов. Продакт менеджер принимает решение, какие платформы нужно поддерживать.


 
Alex Konshin ©   (2008-03-24 13:15) [51]

> Игорь Шевченко ©   (24.03.08 13:10) [49]
> > Откуда такое убеждение?"По плодам их узнаете их" (Матф.
> , VII, 20)

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


 
Игорь Шевченко ©   (2008-03-24 13:17) [52]

Alex Konshin ©   (24.03.08 13:15) [51]

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


 
Alex Konshin ©   (2008-03-24 13:21) [53]

> Игорь Шевченко ©   (24.03.08 13:17) [52]
> Alex Konshin ©   (24.03.08 13:15) [51] Не знаю, дизайн как
> дизайн, бывает лучше (у MS например), бывает хуже. А продукты
> работают и пользуются массовым спросом, наверное это дает
> основание для выводов.

Миллион леммингов не может ошибаться?
Это маркетинг. Это не значит, что нет более правильных продуктов. Качество продукта и спрос не связаны напрямую. И помимо качества спрос учитывает множество других факторов, например, поддержку и брендовость продукта.


 
31512   (2008-03-24 13:22) [54]


> Alex Konshin ©   (24.03.08 13:12) [50]

Если так, то я начинаю понимать откуда в IT появляются продукты и платформы качества "фу!".


 
iZEN   (2008-03-24 14:45) [55]


> Игорь Шевченко ©   (24.03.08 10:34) [35]
>
> Alex Konshin ©   (24.03.08 10:32) [34]
>
> Отсюда вывод - не стоит применять Java для таких приложений
> (24/7) :)
>

Отсюда вывод: писать на C++ тем более нельзя. :)


 
Jeer ©   (2008-03-24 14:53) [56]

Если кто видел SPSS (софт типа "Statistika") ранних версий и последнюю версию 16 сделанную на Java, тот определенно скажет, имея в виду быстродействие: "Все, что угодно, но только не на Java"
Я - видел. Поэтому пользуюсь v.12

Мы, конечно, можем подумать, что в SPSS работают неумехи, но только ли дело в этом ?


 
iZEN   (2008-03-24 14:56) [57]


> Jeer ©   (24.03.08 14:53) [56]
<..>
> Мы, конечно, можем подумать, что в SPSS работают неумехи,
>  но только ли дело в этом ?

А в чём?

Java предполагает определённую (уж точно не низкую) квалификацию проектировщика и кодера. Математеки же могут написать программу на Фортране на любом языке программирования. :)


 
iZEN   (2008-03-24 14:59) [58]


> Reindeer Moss Eater ©   (24.03.08 10:42) [36]
>
> Важно: я точно сказать не могу, не я решаю, но по опыту
> могу сказать, что речь идет о ПО стоимостью СОТНИ тысяч
> $.
>
> Ну за такие-то бабки можно не лениться и отдельные релизы
> под все платформы наваять.


К сожалению цена надёжности не измеряется в деньгах. ;)


 
Reindeer Moss Eater ©   (2008-03-24 14:59) [59]

а в чем?
в попугаях?


 
Jeer ©   (2008-03-24 15:01) [60]


> iZEN   (24.03.08 14:56) [57]


> А в чём?


А не знаю, причем расчетная часть еще ничего, а вот интерфейсная просто выводит из себя своей медлительностью.


 
iZEN   (2008-03-24 15:12) [61]


> Jeer ©   (24.03.08 15:01) [60]
>
> > iZEN   (24.03.08 14:56) [57]
>
> > А в чём?
> А не знаю, причем расчетная часть еще ничего, а вот интерфейсная
> просто выводит из себя своей медлительностью.


Вы давно JVM и JRE обновляли? Поставьте лучше эту: http://download.java.net/jdk6/
(там для своей платформы выберете нужную JRE или JDK).

Кстати, на Swing-интерфейсе сделано куча продуктов:
http://java.sun.com/products/jfc/tsc/sightings/index.html
и тут немножко:
http://www.netbeans.org/features/platform/screenshots.html (это на NetBeans Rich Client Platform).
Ну раз делают, значит это кому-нибудь нужно.

Прошу прощения за оффтопик в теме.


 
iZEN   (2008-03-24 15:21) [62]

По теме

Рекомендую почитать статьи: http://www-128.ibm.com/developerworks/ru/java/


 
Mystic ©   (2008-03-24 17:28) [63]

> Java предполагает определённую (уж точно не низкую) квалификацию
> проектировщика и кодера. Математеки же могут написать программу
> на Фортране на любом языке программирования. :)


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

Во-вторых, программируя на C/C++ я знаю, что мне придется следить за всеми ресурсами самому. И это не сложно. Я не виду трудности ни в написании крассплатформенного кода, ни в реализации многопоточности на C++, ни в том, чтобы избежать memory leaks, а также в других пунктах, которые перечислены уважаемым Alex Konshin. Как говорится, все в моих руках, все под моим контролем, ошибки проявляются быстро, если есть ошибка, то она в моем коде. Что касаемо Java, часть этих проблем Java берет на себя. Но при написании приложений 24/7 надо очень точно представлять, что происходит на всех уровнях системы. Получается, что я должен четко представлять, как именно JVM выполняет то, что написано мною (знать особенности реализации GC, и многое другое). Получается как бы дополнительный уровень, и ошибки могут быть связаны не только с ошибками в программе, но и в том, что я неправильно понял какую-то строку документации. И такие ошибки могут проявляться далеко не сразу...

В-третьих, для вычислений я бы рекомендовал Фортран:
 1) его просто изучить;
 2) сообщество программистов Фортран ограничено, но очень квалифицировано (если вы видите библиотеку на Фортран, то очень вероятно, что это код высочайшего качества);
 3) встроенный тип матриц позволяет компилятору действительно оптимизировать код;
 4) огромный выбор библиотек, многие из которых вылизывались десятилетиями.


 
Игорь Шевченко ©   (2008-03-24 17:38) [64]

У Java есть одна особенность, уж не знаю, плюс это или минус - разработчики на Java дороже других стоят.


 
31512   (2008-03-24 20:40) [65]


> Игорь Шевченко ©   (24.03.08 17:38) [64]

Ээээээ. А почему? Рискуя сделать неверное предположение: не потому ли, что они знают (или должны знать) многообразие бубнов под разные системы?
И вопрос: откуда такая уверенность? Собственный опыт? Статистические наблюдения? И могу ли я услышать ответ на ской пост [43]? Очень интересно.


 
Anatoly Podgoretsky ©   (2008-03-24 21:08) [66]


> Reindeer Moss Eater ©   (24.03.08 14:59) [59]
> а в чем?

В дураках.


 
Mystic ©   (2008-03-24 21:10) [67]

> И могу ли я услышать ответ на ской пост [43]? Очень интересно.

(1) Такая ситуация возникает достаточно редко. Обычно заказчик выбирает среди нескольких предложений, и необходимо под него подстраиваться. Если у заказчика активно используется Windows, то зачем ему головная боль с *nix-сервером?

(2) Все зависит от того, насколько будет трудоемким кроссплатформенное решение. Если это игровой сервер для какой-нить online-игры, то я не вижу никаких принципиальных проблем, связанных с реализацией кроссплатформенного решения. А вот если говорить о каком-нить решении, которое не зависит от выбора SQL-сервера, то тут в большинстве случаев против. Или это real-time система, как тут не быть завязанным на определенную real-time OS (например, QNX)?


 
Anatoly Podgoretsky ©   (2008-03-24 21:28) [68]

> Alex Konshin  (24.03.2008 13:15:51)  [51]

Чем крупнее контора, тем больше дураков в абсолютном измерение.


 
Юрий ©   (2008-03-24 21:34) [69]

> [68] Anatoly Podgoretsky ©   (24.03.08 21:28)

Как тогда феномен Google объяснить? :)


 
Anatoly Podgoretsky ©   (2008-03-24 21:40) [70]

А что с Google не так?
Ты там работаешь, владеешь инсайдерской информацией по дуракам?


 
Юрий ©   (2008-03-24 21:41) [71]

> [70] Anatoly Podgoretsky ©   (24.03.08 21:40)

Конечными продуктами имею возможность пользоваться, а Вы о чём?


 
Ramakrishna   (2008-03-24 21:42) [72]

Юрий ©   (24.03.08 21:41) [71]

http://lordmaze.livejournal.com/101501.html


 
Юрий ©   (2008-03-24 22:01) [73]

> [72] Ramakrishna   (24.03.08 21:42)

Интересно, что отсюда нужно понять? Может они в Google полы мыли.


 
31512   (2008-03-24 23:06) [74]


> Юрий ©   (24.03.08 22:01) [73]

См.

> Mystic ©   (24.03.08 17:28) [63]


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

Вот вопрос который меня давно интерисует: а что такое квалификация разработчика и как её измерить? Как можно определить что мистер А квалифицированный разработчик, а мистер Б неквалифицированный?


 
Reindeer Moss Eater ©   (2008-03-24 23:09) [75]

Понеслась душа в рай.....


 
31512   (2008-03-24 23:11) [76]


> Mystic ©   (24.03.08 17:28) [63]

Тогда может Visual Basic? Как думаешь, система разработанная будет на нём надёжнее, чем на Java?


 
Alex Konshin ©   (2008-03-25 04:47) [77]


> Юрий ©   (24.03.08 21:34) [69]
>
> > [68] Anatoly Podgoretsky ©   (24.03.08 21:28)
>
> Как тогда феномен Google объяснить? :)

Очень просто: они не жадничают, когда набирают программистов.
Но у них высокие критерии при наборе программистов.
Собственно, это одна из причин их успеха.

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

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

Я, конечно, упрощаю, но корень зла - именно тут.


 
Alex Konshin ©   (2008-03-25 05:07) [78]

> Mystic ©   (24.03.08 17:28) [63]
> Во-вторых, программируя на C/C++ я знаю, что мне придется
> следить за всеми ресурсами самому. И это не сложно. Я не
> виду трудности ни в написании крассплатформенного кода,
> ни в реализации многопоточности на C++, ни в том, чтобы
> избежать memory leaks, а также в других пунктах, которые
> перечислены уважаемым Alex Konshin. Как говорится, все в
> моих руках, все под моим контролем, ошибки проявляются быстро,
>  если есть ошибка, то она в моем коде.

Если проект большой и дорогой, то и разработчиков обычно бывает больше одного. Добиться такой же аккуратности от других разработчиков будет нелегко.
И как ты себе представляешь разработку и поддержку к примеру десятка платформ? Я, например, это очень хорошо представляю, я просто это вижу каждый день на работе. Ведь даже Windows несколько платформ, причём с точки зрения C/C++ 64-bit платформы очень существенно отличны от 32-bit платформ.

Вот и получается, что перед тем как начать разработку собственно приложения, придётся сначала разработать библиотеку под *все* поддерживаемые платформы, наладить сборку и тестирование на всех платформах. Это всё - время, а время - деньги. В случае Java начальные издержки значительно ниже, издержки на тестирование тоже, а сборка так вообще проще в разы (обычно достаточно собирать на одной платформе).

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


 
alxt   (2008-03-25 07:52) [79]

Забавный тред.
Уточню.
Были поставлены эксперементы по скорости- при чтении/записи БД (где проигрышь java велик хотя бы из-за большей возни с памятью и теми самыми строками, которые в ней динамические) проигрышь был 5-10%. Промасштабировали в 10 раз - то же самое. В общем- не критично.

Про утечки памяти- пока я занят другой работой, и больше, чем на ночь не запускал тесты. А за ночь потребление ОЗУ выросло на 5% (ровно как на Сишном коде). При том, что постоянно идёт выделение и выбрасывание памяти. jvm 1.6 естественно- известные прошлые грешки сборщика мусора мне не нужны.

Вро машинки у заказчиков. Уважаемый "Автор темы" забыл, что под этот софт будут покупаться отдельные машинки (иначе вся затея теряет смысл), а там уж можно и сказать, мол не надо, например, hp/ux. Да и 32бита вряд ли у кого встретится. А sun и ibm на своих ОС обеспечивают поддержку jvm (у IBM"а, кстати, есть своя версия, которая жестко привязана к их железу). Про Windows не серверах, слава богу, никто не слышал (моя утилитка, напрочь не переваривающий виндовые сервера, не вызвал ни у кого возражений).

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

PS: насколько я понял, только Alex Konshin сравнивает java и C++ на собственном опыте, а не "Абрам напел".

PPS: что "все программисты за java" это я не заметил. Собственно, спор пока ведется вдвоём :)


 
Игорь Шевченко ©   (2008-03-25 09:39) [80]

31512   (24.03.08 20:40) [65]


> Ээээээ. А почему?


Эээээ. А по объявлениям.


>  И могу ли я услышать ответ на ской пост [43]?


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


 
keon ©   (2008-03-25 11:22) [81]


> 3) Ресурсоемкость JAVA. Был опыт: при простой замене парсера
> с perl на JAVA, требования к ресурсам возросли в 10(десять)!
> !! раз (CPU+память).


эт смотря как парсить)
у мну тож такие траблы были, XML из 3000 нодов парсился секунды 3 и более, а потом был переписан и парсился не более 700мс.
Так что проблема была не в Жабе, а в подходе)


 
keon ©   (2008-03-25 11:47) [82]


> Alex Konshin ©   (25.03.08 04:47) [77]
>
>
> > Юрий ©   (24.03.08 21:34) [69]
> >
> > > [68] Anatoly Podgoretsky ©   (24.03.08 21:28)
> >
> > Как тогда феномен Google объяснить? :)
>
> Очень просто: они не жадничают, когда набирают программистов.
>
> Но у них высокие критерии при наборе программистов.
> Собственно, это одна из причин их успеха.
>
> При таком подходе можно получить команду с низким количеством
> дураков.
> Но в подавлющем большинстве софтверных фирм (особенно если
> они публичные - акционированы и их акции на бирже) подход
> к набору программистов и к определению уровня их зарплаты
> совсем иной. Они экономят на зарплате. Стремятся набрать
> людей по-больше, но по-дешевле. Отсюда, кстати и тенденция
> к аутсорсингу в Индию - там программисты дешевые (а вот
> качество - слабое), примерно в 6 раз дешевле программиста
> в Америке.
>
> И я уже понимаю почему это так. Суть проблемы в том, что
> топ менеджеры фирмы не заинтересованы напрямую в качестве
> продуктов. Они заинтересованы в росте цены акций фирмы (причём
> лично и кровно заинтересованы). А на неё гораздо большее
> влияют такие факторы, как размер расходов (и как одна из
> существенных частей - затраты на рабочую силу), размер доходов
> (а тут важны контракты, где гораздо важнее личные связи,
>  чем какой-то там продукт). Вот и получается, что по-большому
> счёту качество продукта - дело десятое. Достаточно просто
> регулярно выпускать новые версии (чтобы качать деньги из
> существующих клиентов), обеспечить поддержку (с той же целью),
>  ну и всеми правдами и неправдами добиваться новых контрактов.
>
>
> Я, конечно, упрощаю, но корень зла - именно тут.


ноу комментс
абсолютно согласен и поддерживаю
сам работаю почти (а может и на все 100%, мож я просто оптимист и занижаю оценку:)) по такой схеме, и в проектах много приоритетов, но только не качество выходного продукта, как говорится: "А получится у нас то, что получилось" :)))
обыдно, а ведь хочется чото сделать толковое, а выходит гафно!


 
dr Gonzo   (2008-03-25 11:55) [83]

Сервера wow, lineage и др массовых онлайн игр написаны на c++.
Замечу, что сложность логики и отказоустойчивости там сопостовима с биржами.


 
DrPass ©   (2008-03-25 12:38) [84]


> Сервера wow, lineage и др массовых онлайн игр написаны на
> c++.
> Замечу, что сложность логики и отказоустойчивости там сопостовима
> с биржами.

Но с другой стороны, биржи обычно пишутся на Java, и работают не хуже Lineage :)
Если серьезно, то онлайн-игра относится к тем продуктам, за которые народ действительно "голосует рублем", так что там подход к разработке и тестированию более серьезный. Но и себестоимость/время разработки будет заметно выше.


 
Mystic ©   (2008-03-25 13:04) [85]

> Если проект большой и дорогой, то и разработчиков обычно
> бывает больше одного. Добиться такой же аккуратности от
> других разработчиков будет нелегко.


Я про это уже говорил в [28]. Но аккуратность при разработке 24/7 необходима вне зависимости от языка разработки.

> И как ты себе представляешь разработку и поддержку к примеру
> десятка платформ? Я, например, это очень хорошо представляю,
>  я просто это вижу каждый день на работе. Ведь даже Windows
> несколько платформ, причём с точки зрения C/C++ 64-bit платформы
> очень существенно отличны от 32-bit платформ.


С десятком платформ у меня не было опыта. Был опыт разработки под четыре платформы: Windows 32 bit, Windows 64 bit, Linux 32 bit, Linux 64 bit. Задачи были не сложные, но каких либо проблем я не обнаружил. Если с самого начала на это закладываться. Разрабатывалось все на одном компьютере, тестировал на Win64 и Linux64. После разработки выслал исходники и тесты другу, он их пересобрал на 32-bit-ных платформах, запустил, сказал что все ок.

> А проблемы С++ возникнут не сейчас, в тестовых приложениях,
>  а при работе с сетью и многопоточностью (и количество траха
> тут, насколько я понимаю, несравнимо).


Не так страшен черт, как его малюют.


 
Evgeny V ©   (2008-03-25 13:44) [86]


> @!!ex ©   (22.03.08 17:05)

Как дополнение  к выбору (не споря о надежности того или иного варианта)
Выбирать я так понимаю еще прийдется и инструментарий....

  Писать в блокноте не очень удобно, писать сеть, работу с СУБД, работу с разными  потоками на чистом  с/с++ под разные платформы - это тоже будет дополнительная работа и не думаю, что простая. Значит прийдется брать какой-либо фреймворк типа QT или GTK, если у вас его еще нет (возможно есть и другое что-то - я просто не в курсе).  Тоже как камушек на ту или иную чашу весов. И в любом случае не забываем о лицензионных соглашениях при выборе того или иного варианта.
   
     Писать  надо на том, чем хорошо владеешь, какой-бы надежный язык не был, наляпать ошибок по незнанию языка или платформы можно в два счета (ИМХО).  
А если существует фактор времени и надо учить новое....а времени мало...  - это еще один аргумент в сторону надежности.

 Мои предпочтения - я бы наверное выбрал JAVA, хотя в ней я как раз и не спец:-)  Но мне кажется, что голосованием такое не решается. Вам должно быть виднее, что вы знаете, что вы имеете и сколько у вас времени.


 
Mystic ©   (2008-03-25 14:31) [87]

Несколько мыслей моего приятеля:

1. Грамотное сетевое приложение и на джаве не просто написать.

2. На самом деле при разработке сложного приложения всегда нужно хорошо продумывать время жизни объектов. И сборщик мусора здесь часто мешает.

3. Java и .NET дают бенефит на мелочи, когда быстро надо че то накидать.

4. Java это неплохо, но иногда надо в ухе отверткой поковыряться а оно не дает :)

5. Когда я пишу .NET мне не хватает автоматического вызова деструкторов.


 
31512   (2008-03-25 14:45) [88]


> Mystic ©   (25.03.08 14:31) [87]


> 5. Когда я пишу .NET мне не хватает автоматического вызова
> деструкторов.

Странно.
http://msdn2.microsoft.com/en-us/library/66x5fx1b.aspx
Согласно этому как раз они и вызываютя автоматически...
Destructors cannot be defined in structs. They are only used with classes.

A class can only have one destructor.

Destructors cannot be inherited or overloaded.

Destructors cannot be called. They are invoked automatically.

A destructor does not take modifiers or have parameters.


 
Mystic ©   (2008-03-25 14:51) [89]

> Согласно этому как раз они и вызываютя автоматически...

Да, но только когда сборщик мусора будет освобождать память. Попробуй в ASP.NET приложении открывать соединение и не закрывать его :) Смысл using как раз и состоит в том, чтобы автоматически вызывать Dispose();


 
Evgeny V ©   (2008-03-25 14:52) [90]


> Mystic ©   (25.03.08 14:31) [87]



> 4. Java это неплохо, но иногда надо в ухе отверткой поковыряться
> а оно не дает :)

С этим согласен, хотя для отвертки есть JNI например


> 3. Java и .NET дают бенефит на мелочи, когда быстро надо
> че то накидать.

А тут можно и про дельфи вспомнить, а реклама QT - советую почитать, то же самое один в один - "...можно написать гораздо быстрее чем в JAVA..." -это про менеджер компоновки например они писали.


> 1. Грамотное сетевое приложение и на джаве не просто написать.

А где его просто написать? Но плюс там вижу - BigEndian независимо от платформы(хотя это и не только к сети относится).  Если надо другой вариант, то можно сделать, есть соотвествущие методы.


> 2. На самом деле при разработке сложного приложения всегда
> нужно хорошо продумывать время жизни объектов. И сборщик
> мусора здесь часто мешает.


За все надо платить, есть преимущества- значит есть и недостатки, если это конечно недостаток:-)  Это относится ко всему мне кажется

Пункт 5 я не понял, или боюсь, что не правильно понял, что  почти одно и тоже:-)


 
31512   (2008-03-25 14:59) [91]


> Evgeny V ©   (25.03.08 14:52) [90


> А тут можно и про дельфи вспомнить, а реклама QT - советую
> почитать, то же самое один в один - "...можно написать гораздо
> быстрее чем в JAVA..." -это про менеджер компоновки например
> они писали.


Реклама на то и реклама, что бы подать то, что в действительности нету.
Сейчас я занимаюсь разработкой на Qt под Linux системы управления комплексом сепараторов руды.
Qt - во многом не даёт того, что зявлено. В частности той же кроссплатформенности. Я не говорю об отсувствии более менее вменяемой среды проектирования GUI. И опять же ручно работы в сотни раз больше чем в Delphi с её VCL. А жирные исполняемые файлы? А море багов в трудно доступных местах? Можно до бесконечности продолжать.


 
Mystic ©   (2008-03-25 15:02) [92]

> Evgeny V ©   (25.03.08 14:52) [90]

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

По поводу 5, как по мне, было бы хорошо предоставить возможность программисту создавать объекты, для которых Dispose вызывался сразу же, как только обнулялся счетчик ссылок + слабые ссылки (weak references).


 
31512   (2008-03-25 15:14) [93]


> Mystic ©   (25.03.08 14:51) [89]

Сборщиком мусора модно управлять
http://msdn2.microsoft.com/ru-ru/library/fs2xkftw(en-us,VS.80).aspx#Mtps_DropDownFilterText
http://msdn2.microsoft.com/ru-ru/library/ddae83kx(en-us,VS.80).aspx
http://msdn2.microsoft.com/ru-ru/library/w908yt2c(en-us,VS.80).aspx
http://msdn2.microsoft.com/ru-ru/library/system.gc(en-us,VS.80).aspx


 
31512   (2008-03-25 15:15) [94]

Я бы даже сказал нужно управлять...


 
Mystic ©   (2008-03-25 15:37) [95]

> 31512   (25.03.08 15:14) [93]

Хорошо, приведи пример кода, чтобы метод Dispose() был вызван в точности в момент, когда на объект более никто не ссылается?


 
31512   (2008-03-25 15:52) [96]


> Mystic ©   (25.03.08 15:37) [95]

Не смогу. Ибо такого я не знаю. Хотя покопаться было бы интересно. Вероятно, что и такое возможно. А может и нет. Не знаю.


 
Поп Гапон   (2008-03-25 16:13) [97]


> Evgeny V ©   (25.03.08 14:52) [90]
>
> А тут можно и про дельфи вспомнить, а реклама QT - советую
> почитать, то же самое один в один - "...можно написать гораздо
> быстрее чем в JAVA..." -это про менеджер компоновки например
> они писали.


Угу, только QT стоит 5200 евро на разработчика, а евро в последнее время подорожал. Много руководителей согласятся купить программный пакет стоимостью с бюджетную иномарку?


 
Mystic ©   (2008-03-25 16:26) [98]

> Не смогу. Ибо такого я не знаю. Хотя покопаться было бы
> интересно. Вероятно, что и такое возможно. А может и нет.
>  Не знаю.


Чтобы это можно было реализовать, необходимо чтобы в момент освобождения/переприсваивания ссылки была возможность определить, что объект никому не нужен. Если бы было идеальное решение, которое бы приемлемо работало во всех случаях, то никаких проблем для disposable объектов бы и не было. Вопрос в том, что такой панацеи нет. Но есть частичные решения, которые работают не всегда. Это
1) auto_ptr, или передача владением объекта. При присваивании оригинал обнуляется. Находит очень узкое применение, но иногда самое то.
2) Подсчет ссылок (более общая конструкция, но не работает для циклических ссылок)
3) Слабые ссылки, предоставляют программисту дополнительно регулировать процесс подсчета ссылок. Если на объект указывают только слабые ссылки, то он разрушаются, а все слабые ссылки обнуляются.


 
DrPass ©   (2008-03-25 16:28) [99]


> Угу, только QT стоит 5200 евро на разработчика, а евро в
> последнее время подорожал. Много руководителей согласятся
> купить программный пакет стоимостью с бюджетную иномарку?
>

Хороший пакет Java-инструментария от IBM потянет по цене на Лексус в базовой комплектации.


 
31512   (2008-03-25 17:03) [100]


> DrPass ©   (25.03.08 16:28) [99]

И в IBM и в TrollTech (которую недовно купила компания Nokia) топ менеджеры хотят ездит на Lexus. :-)))


 
Evgeny V ©   (2008-03-26 06:27) [101]


> Mystic ©   (25.03.08 15:02) [92]



> По поводу 5, как по мне, было бы хорошо предоставить возможность
> программисту создавать объекты, для которых Dispose вызывался
> сразу же, как только обнулялся счетчик ссылок + слабые ссылки
> (weak references).


Вам тогда оберон - Блэк Бокс.:-)) Для соединений с БД там по крайней мере вроде так...  
Это удобно, но... что бы это работало например в JAVA или .NET  мнгновенно или быстро  - это должно делаться не сборщиком мусора, который запускается когда он посчитает это нужным, а который работал бы по другому принципу...


> 31512   (25.03.08 14:59) [91]


> Поп Гапон   (25.03.08 16:13) [97]


В приципе я к тому и веду... Что определяясь  с инструментом, зачастую меняешь позицию



Страницы: 1 2 3 вся ветка

Текущий архив: 2008.05.11;
Скачать: CL | DM;

Наверх




Память: 0.82 MB
Время: 0.025 c
6-1186234118
r.o.o.t
2007-08-04 17:28
2008.05.11
Организация тунеля помогите...


2-1208165182
pathfinder
2008-04-14 13:26
2008.05.11
Уничтожение объекта.


2-1208175871
assassin8899
2008-04-14 16:24
2008.05.11
AQL запрос


2-1208195427
San1712
2008-04-14 21:50
2008.05.11
Как скопировать поля Items[0].Caption и Items[0].SubItems ?


2-1207839420
Vanis
2008-04-10 18:57
2008.05.11
Отрисовка картинок