asiaque <a...@w...hell.pl> napisał(a):

> Wojciech Bańcer <p...@p...pl> wrote:
> > Nikt tu nie pisał, że Java jest narzędziem do wszystkiego. Ale tak się
> > składa, że aplikacje sieciowe i mobilne, to ostatnio bardzo mocno
> > rozwijający się rynek. A J2EE poruszany w temacie wątku, to jak najbardziej
> > zastosowania serwerowe, a nie desktopowe.
>
> No to w takim razie z punktu widzenia osoby zajmującej się na co dzień
> utrzymaniem parunastu/parudziesięciu aplikacji J2EE w najróżniejszych
> środowiskach, darmowych i komercyjnych, pod najróżniejszymi JVM-ami:
> - są o wiele bardziej zasobożerne od ich funkcjonalnych odpowiedników
> pisanych w C/C++ (jak raz parę możliwości porównania mam, to wiem);
> - ciekną - w garbage collector uwierzę jak zobaczę ;)
> - ohydnie logują (nie wątpię, że dla programisty kilometrowe zrzuty z
> wyjątków są wybitnie przydatne, ale mówimy o systemach oddanych do
> eksplotacji); alternatywa "logować mniej/nic" nie wchodzi w grę;
>
> Krótko mówiąc, w utrzymaniu bywają prawdziwym bólem w dupie. Tak jakby
> były pisane dla programistów, nie dla odbiorców. Potwierdza się to zresztą
> gdy napotkasz na jakąkolwiek zagwozdkę związaną z utrzymaniem i szukasz
> pomocy w dokumentacji. "Tu sobie dopisz fooshmoo, tu sobie zrekompiluj, tu
> w tej klasie popraw to i tamto".

Tak z ciekawosci: a co z maintenance contract? Zwykle, jak sie oddaje
aplikacje, jest zawierany rowniez paroletni maintenance contract i w przypadku
ciekniecia (ktore konczy sie pieknym OutOfMemoryError) czy innych bledow -
jest psim obowiazkiem odpowiedniej firmy to naprawic. Administrator nic nie
powinien poprawiac w zadnej klasie, zwlaszcza, ze zwykle jest to nielealne.


A.

--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/