Надежность 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 евро на разработчика, а евро в последнее время подорожал. Много руководителей согласятся купить программный пакет стоимостью с бюджетную иномарку?

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

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

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

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

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

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

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

> 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]

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

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