Sun расширяет спектр Linux ПО

Угу. На жабе? Спасибочки. Иначе был Linux станет Slownux.

>Иначе был Linux станет Slownux.

Ну .... это помоему слишком сильное заявление. Java очень расточительна
в использовании ОЗУ - это точно. Для жаба-кодера 10M-15M - это не цыфра,
в то время C/C++/ADA/FORTRAN/OCaml ... (что самое поразительное даже Python ) кодер должен изрядно постараться чтобы утилизировать это
ОЗУ ( если конечно он не полный идиот ). За примером не нужно далеко
ходить - возьмите хотябы ЛЮБУЮ ОС известную вам и посмотрите сколько
потребляет ядро в пике и SwingSet2. Х.з. не хочу разводить флейм,
но мне кажется, что как говорят буржуины java is very BAD engineered
system. Плюс дурацукая и непроработанная объектная модель.

Предвижу стандартный ответ - купи побольше ОЗУ. Купить то конечно можно
все, но ведь так можно и до маразма дойти - я как то видел заметку, там
ребята на жабе слабали СУБД, которая хранится исключительно в ОЗУ.
Так вот они говорили что зачем мол нам на диск писать IBM вот объявила
о разработке чипов на 1TB - скоро сделают - покупайте, пользуйтесь.

На самом деле ты немного не прав. Конечно, Java требует много памяти, но объем потребленной ею пямяти мало зависит от сложноти программы, т.е. основной кусок памяти жрет виртуальная машина, а не программа. Простая гуйная программа занимает 50 МБ, а сложный сервер приложений 100.
Ну тут опять подмена понятий - ява не для того, чтобы экономить оперативную память, а для того, чтобы быстро и качественно писать кроссплатформенные приложения.
Насчет объектной модели ты особенно гонишь - видимо мало с ней знаком. Объектная модель одна из самых проработанных (из тех, что я видел. Конкурировать в проработанности с ней может только API BeOS).

Такое впечатление что предыдущие авторы живут на Луне и не знают о том, что Java Application Servers являются самым распространённым инструментом для создания инфраструктуры. Организация, которая будет эту инфраструктуру использовать, приобретёт WebLogic от BEA или WebSphere или Open Sourced JBoss. И уж точно - подходящее железо.

>мало зависит от сложноти программы, т.е. основной кусок памяти жрет
>виртуальная машина, а не программа. Простая гуйная программа занимает
>50 МБ, а сложный сервер приложений 100.

Вы уважаемый видимо не видели ничего сложнее томката с сервлетом типа
'привет мир', или просто лжете.

>Ну тут опять подмена понятий - ява не для того, чтобы экономить
>оперативную память

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

>Насчет объектной модели ты особенно гонишь - видимо мало с ней
знаком.
>Объектная модель одна из самых проработанных (из тех, что я видел.
>Конкурировать в проработанности с ней может только API BeOS).

Э ... пардон однако. Я похоже не туда попал ...

По проработке объектная модель жабы откровенно хреновая, особенно базовые классы (что живут в package java). Это и не удивительно, учитывая, когда они дизайнились... Но оно свое все равно берет за счет масштабности. Просто альтернативы нет, и сделать ее за приемлимый срок - нереально.

> По проработке объектная модель жабы откровенно хреновая,

Вы бы пояснили эту простую, но в то же время великую мысль. Чем хреновая? По сравнению с чем? По сравнению с Perl она просто идеальная!

SwingSet zanimaet <10Mb. Java zanimaet BOL'SHE pamyati, no ne nastol'ko (+ paru bait na object reference). Delo v tom GDE hranitsya programma - Zapustite task manager i posmotrite skol'ko u VAS pamyati - eto to, chto zanimaet WINDOWS :-) Raznica v tom, chto Java otkusyvaet kusok ot systemy i v nem vse krutitsya, a C/C++ ... kazhdyj raz dolzhny vydelyat' pamyat' (Kstati, blagodarya tomu, chto VM tochno znaet, gde, kto, gogda zabral pamyat' GC mozhet rabotat' OCHEN' effektivno). Teper' o horoshem (i ne ochen'). esli zapuskaetsya 2 Java progi - zapuskaetsya 2 (!) virtual'nye mashiny i reserviruetsya pamayt' pod 2 (!) programmy. Tiger (1.5) pozvolit ispol'zovat' tol'ko 1 mashinu dlya raznyh prog. dlya 1.6 obeschayutsya zapihnut' VM v service i zapuskat' VSE progi v odnoj kuche (kak eto delaet OS). Poslednee OCHEN' slozhno v vidu osobennostej VM (nu oblazhalis' ponachalu...) Dazhe prosto zapustit' vse s odnoj mashinoj ta esche zadacha (kak byt' s razdelyaemymi resursami, security...)

> Вы уважаемый видимо не видели ничего сложнее томката с сервлетом типа 'привет мир', или просто лжете.

А ты, наверное, разрабатываешь прогаммы в разы сложнее томката?

> Можно найти кучу средств на чем можно писать быстрее ... и надежнее.

Например? А то звучит похоже на это: "У нас есть ТАКИЕ приборы, но мы вам про них не расскажем!"

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

Да что ты говоришь? Ты, случайно, не на бейсике пишешь? Люди, конечно - самое главное, но инструментарий и язык - это второе.

И приведи пример хорошо продуманной, по твоему, объектной модели.

Вообщем один сплошной прогон. Ну кушает память, любит значит. И в то же самое время - альтарнатив то нету. Мне главное, что нескольео томкатов на стандартной машине с 512 памяти выполняет свою работу с нормальными такими аптаймами по пол года, до новой версии. 6 лет пишу на Java и из них только год на awt и год на свинге, да и то в самом начале - не особо актуальны проги на свинге ща - все дела на сервере творятся.
Вообщем сравнил божий дар с яишницей /// Fortran, ADA, C ... еще бы бейсик и паскаль с инлайн ассемблером приплел - LOL
...angryzes...

> Tiger (1.5) pozvolit ispol'zovat' tol'ko 1 mashinu dlya raznyh prog

Этого в 1.5, скорее всего, не будет: http://developer.java.sun.com/developer/bugParade/bugs/4416624.html

>Этого в 1.5, скорее всего, не будет: http://developer.java.sun.com/developer/bugParade/bugs/4416624.html Вообще можно свой лаунчер написать, который из метода главный вызовет несколько прог сразу - не очень актуально для десктопа, но для сервера прокатит. Правда статика будет глючить если несколько инстанций одной проги - но енто смотря какой дизайн - вон пятеро гиперёжиков вместе хорошо бегают под одной ВМ

ООП - вообще дерьмо

maxcom, ну что же Вы так? Глупости же получаются, если buzzwords ещё и пытаться на русский переводить. Ну какое, в баню, "серверное ПО Java"? Речь идёт о Java Enterprise System.

хе, хе :)
приятно наблюдать что жабисты, после того как их жалкая жаба сбохла, и типерь никому не нужна, начинают тут брызгая слюною доказывать обратное :) это просто LOL 8)))))

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

Слово "качественно" выброси. Да и насчёт "кросплатформенности" тоже не всё просто.

>> Можно найти кучу средств на чем можно писать быстрее ... и надежнее.

>Например? А то звучит похоже на это: "У нас есть ТАКИЕ приборы, но мы вам про них не расскажем!"

Ocaml

На васик не наезджать!!!!

на васике была первая ББС-ка написана!!!!

И чем тебе объектная модель Перла на угодила????

Мне кажется что общая направленность идей(хотя они не новы) реализованных в Java и наступление времени когда эти идеи в нормальной реализации стали востребованны и есть привлекательность Java приложений. В качестве примера можно привети что даже Microsoft взяла свой J++ чуть чуть пригладили, чуть чуть синтаксис изменили, много много маркетинга и получилось .NET.

Вадим.

>И приведи пример хорошо продуманной, по твоему, объектной модели.

.NET

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

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

>> И приведи пример хорошо продуманной, по твоему, объектной модели.

> .NET

Так это же объектная модель Java с некоторыми изменениями, причем не всегда в лучшую сторону. Можно же было попробовать учесть опыт эксплуатации Java с 1995 года.

> И чем тебе объектная модель Перла на угодила????

Какая разница, какая там модель, если этот интерпретируемый язык, мягко говоря, не очень хорошо подходит для разработки серьёзного ПО?

> Ocaml

Да, это действительно классная вещь! Однако что-то библиотек к нему не густо. Да, и как там дела с юникодом?

Кстати, кто-нибудь из здесь присутствующих использует Ocaml на работе?

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

Ты на нем писал? Ты его вообще видел? Или повторяешь слова тупых ананимусов.

>И приведи пример хорошо продуманной, по твоему, объектной модели.
>.NET
Ага особенно ADO.NET напишешь код который одновременно работает и с MS SQL < 7.0 и MS SQL >= 7.0. Причем использует наилучший вариант драйвера для каждого случая. Тогда поговорим.

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

>Ты на нем писал?

Знакомые писали. Плачут кровавыми слезами. Но поздно уже.

>Так это же объектная модель Java с некоторыми изменениями, причем не >всегда в лучшую сторону.

Что из нижеперечисленного есть в Java?: 1. Единый объектный корень System.Object для ВСЕХ типов 2. Делегаты (типизированные указатели на функции) 3. Индексаторы 3. параметры функций по ссылке 4. Свойства, как компилируемая единица 5. Атрибуты

Только не говори, что все это не достоинства и нафиг не нужно. Большой плюс Java в большей распространенности и более-менее развитой кроссплатформенности, да и то, печальный девиз:"Пиши один раз - отлаживай везде" все знают

>Знакомые писали. Плачут кровавыми слезами. Но поздно уже.

Ложноручки - псевдоножки

> Что из нижеперечисленного есть в Java?: 1. Единый объектный корень
> System.Object для ВСЕХ типов 2. Делегаты (типизированные указатели на
> функции) 3. Индексаторы 3. параметры функций по ссылке 4. Свойства,
> как компилируемая единица 5. Атрибуты

Из вышеперечисленного есть:
Единый объектный корень java.lang.Object (кроме простых типов. В 1.5 ввели автоматическое обертывание/развертывание), итераторы (в 1.5 ввели индексаторы, точнее немного другое, но смысл тот-же), параметры по ссылке т.к. все объекты передаются по ссылке (может ты имел в виду по значению?)
Чего нет:
Делегаты - полное противоречие идее ООП. Возможно удобно, но текст программы делает нечитаемым.
Свойства - у меня к ним нейтральное отношение, плюсов в них столько-же, сколько и минусов (небольшой неприятный осадок остался после Delphi/Builder)

И насчет девиза ты не прав, нужно просто писать правильно.
Понятное дело, если писать под MS-JRE, то кроме как под WIN программа больше нигде работать не будет.

> Что из нижеперечисленного есть в Java?: 1. Единый объектный корень System.Object для ВСЕХ типов 2. Делегаты (типизированные указатели на функции) 3. Индексаторы 3. параметры функций по ссылке 4. Свойства, как компилируемая единица 5. Атрибуты

1. В 1.5 будет auto[un]boxing

2. Действительно, указатели нафиг не нужны, т.к. есть виртуальные методы.

3.1 Может быть удобно, как и перегрузка операторов, но не критично.

3.2 Так все объекты передаются по ссылке, не считая удалённых вызовов.

4. JavaBeans (хотя я бы предпочел более явное задание свойств).

5. Будут в 1.5.

Но всё-таки, причём тут объектная модель .Net? Это всё свойства языка C#.

ГА-ГА-ГА-ГА. Анонимусы доводят до слёз своим слепым доверием рекламе.

> Ocaml

А что Ocaml? Что на нем написано вообще?

> И чем тебе объектная модель Перла на угодила????

А где она там, объектная модель?

> Ocaml

Дорогой!!!!! Покажи мне на OCaml фреймворк который сравним по функционалу со свингом? Все что там есть это ограниченный биндинг на liblgtk. И кушает окамл память кушает. Када ты мне напишешь прожку на окамле сомвестимуюпо возможностям с IntelliJ IDEA хотябы 2.5 и покажешь как она поместиться в 30 метров = тогда и будешь этих сказок расказывать. А пока там пик формы Cameleon да MLDonkey - постеснялся бы. Как язык это да - никто не спорит. А как покушать память/возможности/функционал - извини тут пока не с чем сравнивать.

>И приведи пример хорошо продуманной, по твоему, объектной модели. .NET

Гений! .NET это платформа. Где там объектная модель?

> 2. Действительно, указатели нафиг не нужны, т.к. есть виртуальные методы.
Блин всему вас учить нужно, какие нафик виртуальные методы? Inner class или интерфейсы на худой конец. Вот правильный ответ тов.Чемберлену.

> 1. Единый объектный корень System.Object для ВСЕХ типов

Нэ трэба. Используйте те типы, которые идут от общего корня, и будет Вам щастье.

> 2. Делегаты (типизированные указатели на функции)

Нэ трэба. Зачем это нужно? Какое отношение типизированные указатели на функции могут иметь к объектной модели языка?

> 3. Индексаторы

Я такого паттерна не припомню что-то, "индексатор". Извините, я .NET не знаю, Майкрософту не обучен. Излагайте в терминах Гаммы & Co.

> 3. параметры функций по ссылке

А сейчас они как, по значению, что ли? Серьезно? Вы на Java писали вообще?

> 4. Свойства, как компилируемая единица

Что в данном случае означает "как компилируемая единица"? Чем JavaBeans не устраивают?

> 5. Атрибуты

См. пункт 3.1 про индексаторы.

> "Пиши один раз - отлаживай везде" все знают

А Вы как хотели бы, вообще не отлаживать?

Еще один неуч. В FCL'e. Блин столько лет угробили чтобы док-ть что Ява это ПЛАТФОРМА, доказали, что по дороге все объектную модель потеряли???

>> 3. параметры функций по ссылке

>А сейчас они как, по значению, что ли? Серьезно? Вы на Java писали вообще?

А ведь параметры действительно передаются по значению, другое дело, что часто путают ссылку на объект с самим объектом. В функцию (метод) передается не объект, а ссылка на него, и передается она по значению. Это отличается от передачи по ссылке, скажем, в C++.

> Пиши один раз - отлаживай везде

Бывает хуже.

>> 2. Действительно, указатели нафиг не нужны, т.к. есть виртуальные методы.

> Блин всему вас учить нужно, какие нафик виртуальные методы? Inner class или интерфейсы на худой конец. Вот правильный ответ тов.Чемберлену.

Не "или" а inner class, реализующий интерфейс. Но это частный случай. А в общем случае в ООП данная концепция реализуется с помощью виртуальных методов.

> А ведь параметры действительно передаются по значению, другое дело, что часто путают ссылку на объект с самим объектом. В функцию (метод) передается не объект, а ссылка на него, и передается она по значению. Это отличается от передачи по ссылке, скажем, в C++.

_Ссылки на параметры_ передаются по значению, а не сами параметры. Если бы параметры передавались по значению, вызывался бы аналог C++ного конструктора копирования. Этого не происходит.

> _Ссылки на параметры_ передаются по значению, а не сами параметры.

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

Cтрока "SomeObject obj;" в C++ объявляет и определяет объект, в Java это всего лишь ссылка. Соответственно, если мы передадим "obj" по значению, то в C++ произойдет копирование объекта, в Java этого не случиться: внутри метода вы получите _копию_ ссылочной переменной "obj".

s/случиться/случится/

Не выспался, наверное :)

> Я плохо себе представляю, что есть _ссылка на параметр_.

Это, по сути, адрес параметра (так же как и указатель), но над ссылкой запрещены действия адресной арифметики (в отличие от указателя).

Ну хорошо, в .NET есть одна штука, которой явно не достает яве - структуры. Для тех, кто не знает, память под структуры выдяляется прямо из стека без обращения к GC. Во многих случаях это - идеальный вариант для работы с так называемыми "маленькими объектами", такими как итераторы. Только вот не надо говорить, что разница в производительности не заметна - еще как заметна! ;)

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

> память под структуры выдяляется прямо из стека без обращения к GC.

Прямо из стека? То есть, если я в методе создал структуру, после выхода из метода я ее уже не увижу?