Здравствуйте Lloyd, Вы писали:

L>Разве не так правильнее?

L>The JavaMailTM API is implemented as a Java platform optional package and is also available as part of the Java 2 platform, Enterprise Edition. == JavaMailTM API реализован как опциональный пакет Java-платформы, а также может быть доступен как часть J2EE.

Ну хорошо. JavaMail можно скачать отдельно. 2.2М. Плюс к ней нужен JAF — еще 400К. Все это нужно будет включить в дистрибутив продукта.


L>>>Моя фраза касалась вашего утверждения, что apache -- часть Linux. А это, по моему мнению совсем не так, поскольку Apache совершенно сторонний по отношению к Linux продукт. И с тем же успехом можно говорить, что он интегрирован в Windows.
AVK>>Во всех современных дистрибутивах линукса есть апач. Также как во всех современных дистрибутивах виндов есть IIS. Вот и все что я хотел сказать.
L>Дык там мнеого чего есть из этого вовсе не следует, что все, что там есть -- интергрированно.
Что ты понимаешь под термином интегрирован?
И IIS и апач бесплатны. И IIS и апач входят в состав дистрибутивов. И тот и другой можно установить в момент инсталляции самой ОС. И тот и другой можно не ставить. Так в чем отличие то? В том что MS suxx а Linux rulez?

L>>>Нет, я говорил о .Net как об эволюционной ветке развития технологий, предлагаемых Microsoft.
AVK>>Эволюционной? Я бы назвал дотнет революционным для MS. Эволюционным было OLE — OLE 2 — COM — COM+.
L>Эволюционный или революционный, это не столь важно. Я хотел лишь сказать, что раскрываение Mictosoft'ом своих исходных кодов скорее сключение, чем правило.
Что то вас всех тянет на MS поплевать. Мы о конкретных продуктах спорим или о фирме MS?
Я наблюдал историю зарождения негативного отношения к ней с самого начала — технические причины в возникновении такового играют отнюдь не решающую роль. И Sun в свое время ну очень не любил что то раскрывать. И давил конкурентов как мог. И только в пику MS исходники java сделали открытыми. Иначе она просто не пошла бы. И если бы была такая возможность Sun с превеликим удовольствием сделал бы java проприетарной платформой.

Здравствуйте VladD2, Вы писали:

VD> ...
VD> Читая все это складывается впечатление, что самим фактом своего появления .net унизил Яву и Sun...

А что разве не унизил?
Вспомни как это было. В конце 90-х когда Microsoft интересовался JAVA, пытался приручить, одомашнить ее на своей платформе, SUN не на шутку взбунтовалась, типа уберите свои грязные Microsoft'овские лапы от нашей JAVA, и начала доставать бесконечными судебными процессами.
Тогда Microsoft придумал новое название для этой технологии значительно ее улучшил, оптимизировал для своей платформы, короче сделал своей. Хотя на 50% .NET обязан своим появлением JAVA.

И когда Microsot объявил, что в будующих версиях Windows он полностью отказывается от встроенной поддержки Java, и Sun получил то чего так долго добивался. Теперь SUN наоборот начала наезжать на MS за то что он игнорирует Java, но в суд на это подать не могут. :)))
Пытается подбить общественность чтобы повлияли на MS.

А Microsoft тем временем усиленно пытается перетащить Java разработчиков к себе — сделали Java под .NET, конвертер из Java в C#, вобще там целый проект стратегического направления по поводу переучивания Java програмеров — кажется "Jump" называется.
Короче на Windows у Java нет ни малейшего шанса перед .NET. А Win платформ большинство.

З.Ы. И остался SUN у разбитого корытца из-за того что перед Microsoft'ом не правильно себя вел. А мог бы на этом круто навариться.

Здравствуйте AndrewVK, Вы писали:

AVK>Здравствуйте Lloyd, Вы писали:

L>>Разве не так правильнее?

L>>The JavaMailTM API is implemented as a Java platform optional package and is also available as part of the Java 2 platform, Enterprise Edition. == JavaMailTM API реализован как опциональный пакет Java-платформы, а также может быть доступен как часть J2EE.

AVK>Ну хорошо. JavaMail можно скачать отдельно. 2.2М. Плюс к ней нужен JAF — еще 400К. Все это нужно будет включить в дистрибутив продукта.

Я рад, что вы все-таки согласились с тем, что для использования JavaMail вовсе не надо ставить J2EE


L>>>>Моя фраза касалась вашего утверждения, что apache -- часть Linux. А это, по моему мнению совсем не так, поскольку Apache совершенно сторонний по отношению к Linux продукт. И с тем же успехом можно говорить, что он интегрирован в Windows.
AVK>>>Во всех современных дистрибутивах линукса есть апач. Также как во всех современных дистрибутивах виндов есть IIS. Вот и все что я хотел сказать.
L>>Дык там мнеого чего есть из этого вовсе не следует, что все, что там есть -- интергрированно.
AVK>Что ты понимаешь под термином интегрирован?
AVK>И IIS и апач бесплатны. И IIS и апач входят в состав дистрибутивов. И тот и другой можно установить в момент инсталляции самой ОС. И тот и другой можно не ставить. Так в чем отличие то? В том что MS suxx а Linux rulez?

Разве IIS бесплатен (hint: он входит в поставку windows, которая вовсе не бесплатна)?
Apache вполне может не входить в состав дистрибутивов
Я не утвержнал, что MS suxx а Linux rulez.

L>>>>Нет, я говорил о .Net как об эволюционной ветке развития технологий, предлагаемых Microsoft.
AVK>>>Эволюционной? Я бы назвал дотнет революционным для MS. Эволюционным было OLE — OLE 2 — COM — COM+.
L>>Эволюционный или революционный, это не столь важно. Я хотел лишь сказать, что раскрываение Mictosoft'ом своих исходных кодов скорее сключение, чем правило.
AVK>Что то вас всех тянет на MS поплевать. Мы о конкретных продуктах спорим или о фирме MS?
AVK>Я наблюдал историю зарождения негативного отношения к ней с самого начала — технические причины в возникновении такового играют отнюдь не решающую роль. И Sun в свое время ну очень не любил что то раскрывать. И давил конкурентов как мог. И только в пику MS исходники java сделали открытыми. Иначе она просто не пошла бы. И если бы была такая возможность Sun с превеликим удовольствием сделал бы java проприетарной платформой.

Да почему вы считаете, что меня тянет на MS поплевать?. Вовсе нет. Я вполне ею доволен. Просто я утверждал, что открытие MS иходных кодов CLI скорее исключение, чем правило. И на данный момент, это действительно так.

Здравствуйте Silver_s, Вы писали:

SS>З.Ы. И остался SUN у разбитого корытца из-за того что перед Microsoft'ом не правильно себя вел. А мог бы на этом круто навариться.

Ну и дураки. Был же уже такой опыт у IBM с ихней полуосью. Не добазарились с MS и где теперь эта OS/2?

В принципе, это даже хорошо. Я имею ввиду, что от этого выиграем прежде всего мы, разработчики. Вот и MS исходнички открыла, что тоже показатель сурьёзный, а как же, конкуренция понимаешь. Пока они с Саном бьются нам хорошо, плохо будет когда один затопчет другого, т.к. развитие может затормозиться до тех пор пока не появится третий

Здравствуйте Lloyd, Вы писали:

AVK>>Ну хорошо. JavaMail можно скачать отдельно. 2.2М. Плюс к ней нужен JAF — еще 400К. Все это нужно будет включить в дистрибутив продукта.
L>Я рад, что вы все-таки согласились с тем, что для использования JavaMail вовсе не надо ставить J2EE

Да что мне соглашаться то? Я JavaMail пользовался. Тоже скачал JavaMail — он стал просить JAF. Скачал JAF — стало работать. Но — намного проще скачать J2EE — он не такой уж и большой.

AVK>>И IIS и апач бесплатны. И IIS и апач входят в состав дистрибутивов. И тот и другой можно установить в момент инсталляции самой ОС. И тот и другой можно не ставить. Так в чем отличие то? В том что MS suxx а Linux rulez?

L>Apache вполне может не входить в состав дистрибутивов
И IIS тоже
L>Я не утвержнал, что MS suxx а Linux rulez.
Что тогда ты пытаешся доказать?

L>Да почему вы считаете, что меня тянет на MS поплевать?. Вовсе нет. Я вполне ею доволен. Просто я утверждал, что открытие MS иходных кодов CLI скорее исключение, чем правило. И на данный момент, это действительно так.
Что это меняет?

Здравствуйте AndrewVK, Вы писали:

AVK>Здравствуйте Lloyd, Вы писали:

AVK>>>Ну хорошо. JavaMail можно скачать отдельно. 2.2М. Плюс к ней нужен JAF — еще 400К. Все это нужно будет включить в дистрибутив продукта.
L>>Я рад, что вы все-таки согласились с тем, что для использования JavaMail вовсе не надо ставить J2EE

AVK>Да что мне соглашаться то? Я JavaMail пользовался. Тоже скачал JavaMail — он стал просить JAF. Скачал JAF — стало работать. Но — намного проще скачать J2EE — он не такой уж и большой.

AVK>>>И IIS и апач бесплатны. И IIS и апач входят в состав дистрибутивов. И тот и другой можно установить в момент инсталляции самой ОС. И тот и другой можно не ставить. Так в чем отличие то? В том что MS suxx а Linux rulez?

L>>Apache вполне может не входить в состав дистрибутивов
AVK>И IIS тоже
L>>Я не утвержнал, что MS suxx а Linux rulez.
AVK>Что тогда ты пытаешся доказать?

Алексей, я не пытался ничего доказать.
Я просто поправил небольшие неточности, допущенные в ваших сообщениях.
1. Для работы JavaMail нужен J2EE -- неверно.
2. Apache интергрирован в Linux -- тоже неверно.

P.S. Под интегрировнностью я понимаю невозможность сущетствования, того, во что интергировано, без того, что интергрированно.
Пример -- IE интергрирован в Windows.
В этом смысле Apache вовсе не интергрирован в Linux (прекрасно существует и без него).

Здравствуйте Silver_s, Вы писали:

SS>Здравствуйте VladD2, Вы писали:

VD>> ...
VD>> Читая все это складывается впечатление, что самим фактом своего появления .net унизил Яву и Sun...

SS>А что разве не унизил?

Мне кажется, что побидителя унизить невозможно.

SS>Вспомни как это было. В конце 90-х когда Microsoft интересовался JAVA, пытался приручить, одомашнить ее на своей платформе

Да помню... MS предлагал полезные расширения типа делегатов (для реализации событий), а Sun вставал в позу.

Помню так же что Яву от MS никто из виндовс программистов (надеюсь не будешь спорить что пока большинство) была пустым звуком. Я, например, ни разу не проинсталлировал J++ на свою машину. И помню, что была куча фирм которая с азартом бросилась ракапывать рынок Явы. Вто только все эти фирмы (кроме прирученного Борланда, и IBM-а который занимается всем подряд) бросили заниматься развитием Явы. Так что по сути Ява стала таким же частным стандартом как и виндовс. Ничего стршного в этом нет, но и в .Net ничего страшного нет вроде.

SS>, SUN не на шутку взбунтовалась, типа уберите свои грязные Microsoft'овские лапы от нашей JAVA, и начала доставать бесконечными судебными процессами.

Ну и наивный ты, блин. Sun и MS — это мегомонстры приблизительно одинакового размера и одинаковой жадности. Их цель контроль над всем. Думаю в свое время MS предлагал Sun-у вместе срубать бабки с Явы. Sun посчитал, что справится сам. Вот и пусть дерутся.

SS> Тогда Microsoft придумал новое название для этой технологии значительно ее улучшил, оптимизировал для своей платформы, короче сделал своей. Хотя на 50% .NET обязан своим появлением JAVA.

Тебе не кажется, что 50% это слишком большая разница для копии?

От явы конечно взято немало, но и от других языков и систем взято немало. Первые версии Явы бли страшной лажей. Толко к версии 1.3 Ява стала серьезной компонентной средой. Нового в Яве ничего не было. Это как в продуктах MS: берем много правильных, обычно чужих, идей и реализуем. И что волноваться когда MS использует ту же тактику? В конце концов это её тактика.

SS> И когда Microsot объявил, что в будующих версиях Windows он полностью отказывается от встроенной поддержки Java, и Sun получил то чего так долго добивался. Теперь SUN наоборот начала наезжать на MS за то что он игнорирует Java, но в суд на это подать не могут.

Ну? Так оно и есть...
Sun отсудил у MS право на единоличное развитие Явы, а MS получил за эти $20 лимонов право создать ей конкурента. Так что тут плохого?

SS>Пытается подбить общественность чтобы повлияли на MS.

Это было смешно (если ты об открытых письмах).

SS> А Microsoft тем временем усиленно пытается перетащить Java разработчиков к себе — сделали Java под .NET, конвертер из Java в C#, вобще там целый проект стратегического направления по поводу переучивания Java програмеров — кажется "Jump" называется.

Думаю MS бился в основном не за них, а за море виндовс-программистов и за океаны новых. Хотя упускать долю чужого пирога в бизнесе как-то неприлично.

SS> Короче на Windows у Java нет ни малейшего шанса перед .NET. А Win платформ большинство.

У Явы нет ни малейшего шанса перед .Net исключительно из-за раздолбайства Sun-а. Надеюь жареный петух приведет к тому, что Sun возьмется за голову. Битва еще не проиграна. Некоторые маневры Sun-а я лично оцениваю положительно. Например, включение шаблонов в язык это правильный и сильный ход. Придется, правда, еще раз переписать все базовые библиотеки... Однако JNI лажа супротив Interop-а от MS. Да и другие правильные идеи похоже взяты не будут.

SS>З.Ы. И остался SUN у разбитого корытца из-за того что перед Microsoft'ом не правильно себя вел. А мог бы на этом круто навариться.

И чего такого в этом .Net-е.


PS

Расказывать о технических различиях .Net и Явы глупо и скушно. Елси это кому интересно, то кое что есть на русском на этом соайте и на www.optim.ru. Так же советую прочеть вот эти статейки:
http://www.microsoft.com/msj/defaultframe.asp?page=/msj/1197/complus.htm

http://www.microsoft.com/msj/defaultframe.asp?page=/msj/1297/complus2/complus2.htm

Здравствуйте IT, Вы писали:

IT>Ну и дураки. Был же уже такой опыт у IBM с ихней полуосью. Не добазарились с MS и где теперь эта OS/2?

— Вчем правда брат?
— Думаю, правда в силе... Кто сильнее тот и прав.

(с) Куклы, по мативам "Брат 1"

Сейчас IBM усиленно вкладывает деньги в Линукс.

Ктобы обяснил ихним менеджерам, что на есть еще Фришка и разные там Мак ОС 10 (на бсд-шной основе...

IT>В принципе, это даже хорошо. Я имею ввиду, что от этого выиграем прежде всего мы, разработчики. Вот и MS исходнички открыла, что тоже показатель сурьёзный, а как же, конкуренция понимаешь. Пока они с Саном бьются нам хорошо, плохо будет когда один затопчет другого, т.к. развитие может затормозиться до тех пор пока не появится третий

Чем далше в лес...
Тем третий лишний!

(с) Нар. мудрость.

Здравствуйте VladD2, Вы писали:

VD>От явы конечно взято немало, но и от других языков и систем взято немало. Первые версии Явы бли страшной лажей. Толко к версии 1.3 Ява стала серьезной компонентной средой.
Справедливости ради замечу что Java 2 началась с версии 1.2 и многие современные продукты 1.2 compatible

Здравствуйте Lloyd, Вы писали:

AVK>>Эволюционной? Я бы назвал дотнет революционным для MS. Эволюционным было OLE — OLE 2 — COM — COM+.

L>Эволюционный или революционный, это не столь важно. Я хотел лишь сказать, что раскрываение Mictosoft'ом своих исходных кодов скорее сключение, чем правило.

Я бы сказал пока. Но Sun работат над иправлением этого недостатка.

Здравствуйте AndrewVK, Вы писали:

VD>>От явы конечно взято немало, но и от других языков и систем взято немало. Первые версии Явы бли страшной лажей. Толко к версии 1.3 Ява стала серьезной компонентной средой.
AVK>Справедливости ради замечу что Java 2 началась с версии 1.2 и многие современные продукты 1.2 compatible

Справидливости ради можно заметить, что безспорно улучшенные библиотеки в Ява 1.2 (да сих пор не понимаю почему ее назвали "Ява 2" :??? ), мало интересны если не использовать неплохо улучшенного джита из в. 1.3. Хотя конечно если бы небыло изменений в 1.2, то и этот труд был бы напрасным.

Кстати одной из ошибок Sun я считаю разработки спецификации Ява Бобов, а в последствии и Энтерпрайзнутых бобов. Дублирование рефлекшона — это глупость. Эмуляция свойств при полном их отрицании просто нонсенс. Именно из-за таких гулупостей (совершенно мелочных) Sun может и проиграть схватку.

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

Естественно, все это по-моему.

Здравствуйте IT, Вы писали:

ZEN>>Я считаю: меньше размер -- меньше потенциальных ошибок в коде.
ZEN>>Слышали, наверное, о "рекорде" "ServicePack для WindowsXP будет весить 600Мб" -- насколько это сопоставимо с размером самой системы?

IT>Дык, я тут Линукс какой-то видел на 3-х копмактах, что ж теперь считать, что по сравнению с Windows там просто два диска глюков?

А я Сюзу еще года два назад с шести ставил. Там от одних Оракла с IBM-мом на компакт глюков приходилось.

IT>У меня вообще нет модемных линий, ни дома ни на работе, надеюсь, что скоро и у вас их не будет.

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

IT> Именно поэтому, разница в объёме занимаемого дистрибутива между Java и .NET не имеет абсолютно никакого значения и не может служить аргументом. Вот функциональность — да.

Правильно размер не имеет значения! И вообще щастье не в неньгах, а в их количестве.

Я все это к тому, что глупые какие-то рассуждения. Если ух сравнивать продукты, то надо выбрать для этого ниши и сравнивать их исхдя из условия ниш.

На клиенте и Ява и Нэт в основном будут использоваться для создания криентов к КИС и прочим бюзгалтериям. Так вот их не грех и с компакта поставить. А в Вэбнутых приложениях ни один здравых человек ни Нэт, ни Явы с беломор-каналом не поставит. Можно конечно встретить людей засовывающих ActiveX-ы в Эксплорер или до сих пор клепающими аплеты, но разумными эти действия не назовешь. А отучают от таких причуд сами пользователи, которым просто в лом.

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

ZEN>>Читали притчу о Вавилонской башне? Почему её не могли построить, знаете?

IT>Ой, да ладно. Скажи ещё что им просто Java от Sun не хватило, а так бы всё было пучком

Кстати если развивать перенос притчи, то MS получается вроде бога. А с ними лучше не спорить. (все же демогогия убедительная вещь) .

IT>Да уж, приходиться пользовать каждый день как минимум — C++, C#, VB, JScript, T-SQL, XML, HTML, русский, английский Не представляю как всё это можно заменить одной Java

А-га! А в этом русском еще правла понасованы, да еще и компилятора нормального не прилогается. Один Ворд и тот тормозной интерпретатор.

Здравствуйте AndrewVK, Вы писали:

IT>>А это тут причём?
AVK>Это наверное такой способ спора — доказывать не то о чем собственно разговор.

В простонародье называется демогогия. Иногда "диалектическим материализмом", но это конечно заблуждени. .

Здравствуйте iZEN, Вы писали:

ZEN>Цитатка: "Sun Microsystems, Inc. is a company that responds to the needs of the Java technology developers. Version 1.4 is the first J2SE release to participate in the Java Community ProcessSM — an open, community-based process for the development of Java technology specifications, reference implementations and associated technology compatibility kits. Driven by Sun Microsystems, Inc. as Expert Group specification lead, companies such as Borland, Compaq, Fujitsu, SAS, Symbian, and IBM participated in defining and developing J2SE version 1.4 specifications side-by-side with other industry leaders. In all, 39 companies and industry leaders participated in the development of J2SE 1.4, which had a total of 11 Java Specification Requests. The result of this collaborative effort is a high-quality specification that best represents the diversity of the Java community." Источник: http://java.sun.com/j2se/1.4/datasheet.1_4.html

ZEN>Java -- это уже почти не Sun...

Ага. Это MS с человеческим лицом.

Ты главное от MS пресрелизы не читай, а то вон IT уже почти убедил себя, что кроме Web-сервисов в программировании ничего путного нет, а любую RPC-технологию можно замедлить до их скорости.

Здравствуйте VladD2, Вы писали:

VD>Здравствуйте AndrewVK, Вы писали:

VD>Справидливости ради можно заметить, что безспорно улучшенные библиотеки в Ява 1.2 (да сих пор не понимаю почему ее назвали "Ява 2" :???
Очень много изменений, причем некоторые революционные. Там кое какие классы целыми пачками стали deprecated, в частности все коллекции были переписаны по новой.

VD> ), мало интересны если не использовать неплохо улучшенного джита из в. 1.3.
Да нет, JVM более менее приличный был уже начиная где то с 1.1.6. А вот библиотеки боле менее устаканились уже в Java 2.

VD>Хотя конечно если бы небыло изменений в 1.2, то и этот труд был бы напрасным.
1.2 это был большой труд. А вот прожила она совсем чуть чуть, если в плане библиотек 1.2 это стандарт то использовали ее совсем мало. Тут ты прав — реально Java 2 прижилась именно начиная с 1.3 (это на платформе Windows и Solaris, в Линуксе долгое время пользовали 1.2.2, но это отдельный разговор)

VD>Кстати одной из ошибок Sun я считаю разработки спецификации Ява Бобов, а в последствии и Энтерпрайзнутых бобов. Дублирование рефлекшона — это глупость. Эмуляция свойств при полном их отрицании просто нонсенс. Именно из-за таких гулупостей (совершенно мелочных) Sun может и проиграть схватку.
Бобы не дублируют рефлекшн, они его дополняют. Это замена атрибутам в дотнете. Т.е. по сути это даже не библиотека а некий стандарт именования функций (в дотнете подобное кстати тоже есть — обзывать классы драйверов ado.net нужно определенным образом). Сама же библиотека это по большому счету класс Introspector, который просто удобный способ работы с рефлекшеном, не более того. Классы же BeanInfo это просто способ отделить мух от котлет, т.е. рантайм компонент и дизайнтайм данные. Остались классы PropertyEditor — ну тут вобще все как и везде.
Что же касается EJB — тут вобще мимо. Зря наверное их бинами обозвали — ничего общего с обычными бинами они не имеют. Просто словом bean в джаве принято заменять слово component .

VD>Похоже что последний бой еще не состоялся. Все будет зависить от реальных (а не в спецификациях) следующих версих этих продуктов. Sun-у во многом уже нужно догонять, но и MS работенки хватит. Если MS не сделает шаблонов, или сделает, но криво, то у Sun-а открывается огромный шанс отвоевать кусок рынка. Причем все усилия MS при этгм будут играть на руку Sun-у.
Влад, мне кажется значимость шаблонов ты несколько преувеличиваешь. Ну будут они, я думаю ничего кардинально не изменится. Та же Дельфи, при отсутствии шаблонов, множественного наследования и много чего еще вполне успешно конкурирует с С++.

Здравствуйте AndrewVK, Вы писали:

VD>>Справидливости ради можно заметить, что безспорно улучшенные библиотеки в Ява 1.2 (да сих пор не понимаю почему ее назвали "Ява 2" :???:)
AVK>Очень много изменений

Если они посчитали что изменений много, то нужно было довать версию 2 (или 7 как MS), а не заниматься дурью.

AVK>, причем некоторые революционные. Там кое какие классы целыми пачками стали deprecated, в частности все коллекции были переписаны по новой.

Вот уж революционного ни в Яве, ни в Нэте я пока не обнаружил. Грамотные (и не очень) реализации идей дестилетней давности.

Они что идею абстракций или интрфейсов придумали, компонентный подход впревые применили, или хотя бы пи-код придумали? Назови хотябы что-нибцдь, кроме реализации всего этого в рамках одной среды.

VD>> ), мало интересны если не использовать неплохо улучшенного джита из в. 1.3.
AVK>Да нет, JVM более менее приличный был уже начиная где то с 1.1.6. А вот библиотеки боле менее устаканились уже в Java 2.

Что-то я не припомню такой производитеьности даже от 1.2, не то что от 1.1.х. Может конечно я был так сильно разочарован первой версией Явы, что просто плохо смотрел.

VD>>Хотя конечно если бы небыло изменений в 1.2, то и этот труд был бы напрасным.
AVK>1.2 это был большой труд.

Да пришлось выбростить книги Страуструпа и почитать Кнута. ;)

AVK>Бобы не дублируют рефлекшн, они его дополняют.

Ты как нибудь попробуй дополнить пятиканальную долби биджитал систему стереофоническим усилителем. Это будет тоже самое. На хрена козе баян?

AVK> Это замена атрибутам в дотнете.

Не, атрибутами это и не пахнет. Они сдублировали получение информации о компоненте с помошью дополнительных классов. Рефлекшон полность мог бы решить эти задачи, хотя конечно наличие тех же атрибутов сильно упростило бы задачу. Кстити, они вроде их намериваются засунуть в следующую версию. Или я ошибаюсь?!

AVK> Т.е. по сути это даже не библиотека а некий стандарт именования функций

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

AVK> (в дотнете подобное кстати тоже есть — обзывать классы драйверов ado.net нужно определенным образом).

А моло разбирался в ado.net вообще, но точно знаю, что ado.net наследуется от стандартной компонентной архитектуры, а та в свою очередь обходится без промежуточных классов, есть лазы на атрибутах, но общая схема элегантнее на порядок. Видимо сказался опыт в COM и анализ недостатков Явы. К тому же есть штатные свойства (хотя в основном я не о них говорил).

AVK> Сама же библиотека это по большому счету класс Introspector, который просто удобный способ работы с рефлекшеном

Удобный... не удобный. Глваное необходимый. И идеологически лишний. К тому же эта дурная идеология говорит, что якобы компоненты начинаются с бобов, хотя любой скомпилированный класс в Яве является по существу компонентом. В Нэте тоже ввели интерфейс, но он вообще ничего не делает.

AVK>, не более того. Классы же BeanInfo это просто способ отделить мух от котлет, т.е. рантайм компонент и дизайнтайм данные. Остались классы PropertyEditor — ну тут вобще все как и везде.

Эээ... батенька. Нэт обходтися без ненужных примочек. Есть пути порулить, но они опциональные. По умолчанию тоже PropertyEditor пользуется решлекшоном, а значит я могу вывести в него любой объект. И файл ему отдельный с надписью "А точно является компонентом" не нужен. Еджиби же вообще один популизм. Все тоже самое можно было делать и без выделенного класса компонентов. Получается как раз что Sun свалил все в одну тарелку (мух катлеты), т.е. обычные бобы — это визуальные компоненты (типа ActiveX-ы), а Ё-бобы — это уже крутые энтэрпрайзные примочки. Прчем большая часть из них менее функциональны чем обычные бобы. :( Причем самое обидное, что отказаться от всего этого барахла уже будет очень не просто. Даже если появятся атрибуты и прочие вещи.


AVK>Что же касается EJB — тут вобще мимо. Зря наверное их бинами обозвали — ничего общего с обычными бинами они не имеют. Просто словом bean в джаве принято заменять слово component :).

Вот это я называю неграмотным проектированием и ламерской реализацией. К тому же у них есть одна общая вещь... И те и другие компоненты. Хотя чем хуже все остальные???

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

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

AVK>Та же Дельфи, при отсутствии шаблонов, множественного наследования и много чего еще вполне успешно конкурирует с С++.

Не очень то успешно. Только в одной нише (догадайся в кака?).

Здравствуйте VladD2, Вы писали:

VD>Если они посчитали что изменений много, то нужно было довать версию 2 (или 7 как MS), а не заниматься дурью.
Да какая нафик разница. Как не называй, суть то одна.

AVK>>, причем некоторые революционные. Там кое какие классы целыми пачками стали deprecated, в частности все коллекции были переписаны по новой.

VD>Вот уж революционного ни в Яве, ни в Нэте я пока не обнаружил. Грамотные (и не очень) реализации идей дестилетней давности.
Революции разные бывают. Под революцией я понимаю ситуацию, когда приходится отказываться от старых наработок. А что это — какие то глобальные идеи или небольшой класс, не суть важно.

VD>Они что идею абстракций или интрфейсов придумали, компонентный подход впревые применили, или хотя бы пи-код придумали? Назови хотябы что-нибцдь, кроме реализации всего этого в рамках одной среды.
Это революция не вобще, а по сравнению с предыдущей версией.

VD>Что-то я не припомню такой производитеьности даже от 1.2, не то что от 1.1.х. Может конечно я был так сильно разочарован первой версией Явы, что просто плохо смотрел.
Какой такой? 1.1.6 был вполне применим в коммерческих проектах. Скорость его была конечно же поменьше 1.3, но для многих задач вполне достаточна.

VD>Да пришлось выбростить книги Страуструпа и почитать Кнута. ;)
Это между прочим очень серьезно. Народ вон до сих пор по поводу GC возмущается. А тут десятилетия наработок — не так то просто взглянуть на тоже самое с другой стороны.

AVK>>Бобы не дублируют рефлекшн, они его дополняют.

VD>Ты как нибудь попробуй дополнить пятиканальную долби биджитал систему стереофоническим усилителем. Это будет тоже самое. На хрена козе баян?
Рефлекшн джавы не обеспечивает достаточную для реализации визуального программирования функциональность. Там нет способа сказать что тот или иной метод на самом деле property accessor

AVK>> Это замена атрибутам в дотнете.

VD>Не, атрибутами это и не пахнет. Они сдублировали получение информации о компоненте с помошью дополнительных классов.

Влад, BeanInfo можно вобще не писать для компоненты. Это опциональная вещь. Основа java beans это соглашение об именовании методов доступа к свойствам.

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

VD> Кстити, они вроде их намериваются засунуть в следующую версию. Или я ошибаюсь?!
Что то такое они делать собираются.

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

Влад, в данном случае ты просто не в курсе. BeanInfo это вспомогательные классы.
A bean implementor who wishes to provide explicit information about their bean may provide a BeanInfo class that implements this BeanInfo interface and provides explicit information about the methods, properties, events, etc, of their bean.
Обрати внимание, may provide, а не must provide.
Еще одна цитата
To minimize the resources used by a bean, the classes used by bean editors are loaded only when the bean is being edited. They are not needed while the bean is running in an application and therefore not loaded. This information is kept in what's called a bean-info (see BeanInfo).

VD> В Нэте это сделано намного элегантнее,
Согласен. В нете есть свойства и аттрибуты, которые как раз и предназначены прежде всего для решения данной проблемы. В джаве изначально это не сделали (впрочем понятно почему, в момент ее рождения еще непонятно было что и как). А потом менять язык они не захотели. Пока MS не укусил за задницу.

VD> хотя CODEDOM с его недокументированностью получился тяжеловатым и молопонятным.
Вот тут как раз и помогли бы исходники.

AVK>> (в дотнете подобное кстати тоже есть — обзывать классы драйверов ado.net нужно определенным образом).
VD>А моло разбирался в ado.net вообще, но точно знаю, что ado.net наследуется от стандартной компонентной архитектуры, а та в свою очередь обходится без промежуточных классов, есть лазы на атрибутах, но общая схема элегантнее на порядок. Видимо сказался опыт в COM и анализ недостатков Явы. К тому же есть штатные свойства (хотя в основном я не о них говорил).
Так сразу бы и говорил что тебе не нравится механизм BeanInfo, а не java beans. Особенно непонятно при чем здесь EJB.


AVK>> Сама же библиотека это по большому счету класс Introspector, который просто удобный способ работы с рефлекшеном

VD>Удобный... не удобный. Глваное необходимый. И идеологически лишний. К тому же эта дурная идеология говорит, что якобы компоненты начинаются с бобов, хотя любой скомпилированный класс в Яве является по существу компонентом.
Влад, ты просто не в курсе.

VD>В Нэте тоже ввели интерфейс, но он вообще ничего не делает.
Какой интерфейс?

AVK>>, не более того. Классы же BeanInfo это просто способ отделить мух от котлет, т.е. рантайм компонент и дизайнтайм данные. Остались классы PropertyEditor — ну тут вобще все как и везде.

VD>Эээ... батенька. Нэт обходтися без ненужных примочек. Есть пути порулить, но они опциональные.
Ну так BeanInfo и PropertyEditor тоже опциональные.


VD> По умолчанию тоже PropertyEditor пользуется решлекшоном, а значит я могу вывести в него любой объект. И файл ему отдельный с надписью "А точно является компонентом" не нужен.
В джаве все точно так же.

VD> Еджиби же вообще один популизм. Все тоже самое можно было делать и без выделенного класса компонентов.
А его и нет, выделенного класса. Есть только интерфейсы. А базовые классы для EJB у каждого сервера свои. EJB вобще больше похожи на aspx чем на классы как таковые.

VD>Получается как раз что Sun свалил все в одну тарелку (мух катлеты), т.е. обычные бобы — это визуальные компоненты (типа ActiveX-ы), а Ё-бобы — это уже крутые энтэрпрайзные примочки. Прчем большая часть из них менее функциональны чем обычные бобы.
Я уже сказал — бобами их назвали крайне неудачно. Ничего общего с обычными бобами они не имеют.

VD> :( Причем самое обидное, что отказаться от всего этого барахла уже будет очень не просто. Даже если появятся атрибуты и прочие вещи.
Влад, EJB это вобще отдельный разговор. Там все совсем по другому. Сравнивать их с дотнетом сложно, он использует другие способы решения тех же задач.

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

VD>Реальная конкуренция с С++ до реализации дженирик-типов будет сильно ослаблена. БобшАя часть задачь, если не сказать бОльшая пройдет мимо, так как производительность и гибкость (в их случае) окажится на стороне плюсов (пусть даже со всеми их недостатками).
Где то в инете видел исследование — производительность современных компьютеров в 95% случаев избыточна.

VD>Пока есть только одно неоспоримое преимущество — легкая и быстрая реализация компонентов. Это особо актуально для бизнес-приложений, для остальных же все не так однозначно.
Так бизнес-приложения это основные деньги. Завоевать рынок платформ для коробочного софта я думаю ни Sun ни MS особо не стремятся.
Ну а основное преимущество джавы и шарпа в скорости разработки. К примеру тот же развитый рефлекшн по сути замешает темплейты, естественно ценой быстродействия.

VD> А если появятся грамотно реализованные шоблоны, то и этот фиговый листок отпадет за ненадобностью.
Все это очень неоднозначно. Выиграем тут проиграем там.


AVK>>Та же Дельфи, при отсутствии шаблонов, множественного наследования и много чего еще вполне успешно конкурирует с С++.
VD>Не очень то успешно. Только в одной нише (догадайся в кака?).
Тем не менее коммерческий успех есть.

Здравствуйте AndrewVK, Вы писали:

VD>>Если они посчитали что изменений много, то нужно было довать версию 2 (или 7 как MS), а не заниматься дурью.
AVK>Да какая нафик разница. Как не называй, суть то одна.

Неразбериха. Вот суть таких именований.

AVK>Революции разные бывают. Под революцией я понимаю ситуацию, когда приходится отказываться от старых наработок. А что это — какие то глобальные идеи или небольшой класс, не суть важно.

В восьмедисятых для таких преобразований приспособили слово перестройка.

AVK>Это революция не вобще, а по сравнению с предыдущей версией.

Дык если есть версии, то однозначно эволюция. Типа лапки вместо плавников.

AVK>Какой такой? 1.1.6 был вполне применим в коммерческих проектах. Скорость его была конечно же поменьше 1.3, но для многих задач вполне достаточна.

Я о том, что на разницу в двое я глаза еще закрою, но в 10 раз — это уже перебор, а 1.1.х тормозили по черному. Есть задачи не критичные ко времени, но вом мне все как-то другие попадаются.

VD>>Да пришлось выбростить книги Страуструпа и почитать Кнута.
AVK>Это между прочим очень серьезно. Народ вон до сих пор по поводу GC возмущается. А тут десятилетия наработок — не так то просто взглянуть на тоже самое с другой стороны.

Ну, концептуально нового было мало. В основном более грамотные и абстрактные реализации. Страуструп то тоже Кнута читал.

AVK>Рефлекшн джавы не обеспечивает достаточную для реализации визуального программирования функциональность. Там нет способа сказать что тот или иной метод на самом деле property accessor

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

AVK>Влад, BeanInfo можно вобще не писать для компоненты. Это опциональная вещь. Основа java beans это соглашение об именовании методов доступа к свойствам.

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

VD>> Рефлекшон полность мог бы решить эти задачи, хотя конечно наличие тех же атрибутов сильно упростило бы задачу.
AVK>Вот и расскажи как, используя джавовский рефлекшен, это реализовать.

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

AVK>Влад, в данном случае ты просто не в курсе. BeanInfo это вспомогательные классы.

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

AVK>A bean implementor who wishes to provide explicit information about their bean may provide a BeanInfo class that implements this BeanInfo interface and provides explicit information about the methods, properties, events, etc, of their bean.

Я цитаты драть не буду, но помню, что там еще были слова типа "если вам нужно вы можете сварганить все сами...".

AVK>To minimize the resources used by a bean, the classes used by bean editors are loaded only when the bean is being edited. They are not needed while the bean is running in an application and therefore not loaded. This information is kept in what's called a bean-info (see BeanInfo).

Ну, и? Нафига все это при наличие крутейшего решлекшона? Ироткр чибы понять, что getXxx и setXxx являются свойствами? Может проще было в этой Яве 2 свойства добавить с делегатами и не выпендриваться пудря мозги про конноы ОО?

VD>> хотя CODEDOM с его недокументированностью получился тяжеловатым и молопонятным.
AVK>Вот тут как раз и помогли бы исходники.

Кто бы спрорил. Но лучши исходники и документация.

AVK>Так сразу бы и говорил что тебе не нравится механизм BeanInfo, а не java beans. Особенно непонятно при чем здесь EJB.

Дык это и есть главная особенность бобов. Я честно говоря думал Ё-джибя так же сделаны.

VD>>Удобный... не удобный. Глваное необходимый. И идеологически лишний. К тому же эта дурная идеология говорит, что якобы компоненты начинаются с бобов, хотя любой скомпилированный класс в Яве является по существу компонентом.
AVK>Влад, ты просто не в курсе.

Я в курсе, что есть дефолтная реализация.

VD>>В Нэте тоже ввели интерфейс, но он вообще ничего не делает.
AVK>Какой интерфейс?

IComponent

Я честно говоря считаю, что это тоже ошибка. Любой класс должен быть компонентом если это позволяет система. В Нэт и Яве это возможно, но не реализовано. Причем в Яве худшая форма.

VD>>Эээ... батенька. Нэт обходтися без ненужных примочек. Есть пути порулить, но они опциональные.
AVK>Ну так BeanInfo и PropertyEditor тоже опциональные.

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

VD>> По умолчанию тоже PropertyEditor пользуется решлекшоном, а значит я могу вывести в него любой объект. И файл ему отдельный с надписью "А точно является компонентом" не нужен.
AVK>В джаве все точно так же.

Нет, в Яве по умолчанию создается умолчальная реализация всех этих BeanInfo и Introspector-ов, а уже она лезит к компонентам. Получается явная замена рефлекшона. Ольтернатива для получения информации о типах.

VD>> Еджиби же вообще один популизм. Все тоже самое можно было делать и без выделенного класса компонентов.
AVK>А его и нет, выделенного класса. Есть только интерфейсы. А базовые классы для EJB у каждого сервера свои. EJB вобще больше похожи на aspx чем на классы как таковые.

Класное достижение!

VD>>Вот это я называю неграмотным проектированием и ламерской реализацией. К тому же у них есть одна общая вещь... И те и другие компоненты. Хотя чем хуже все остальные???
AVK>Проектирование то тут при чем? Просто не очень удачное название.

Дык все эти Явы и Нэты спроектированы били...

AVK>Где то в инете видел исследование — производительность современных компьютеров в 95% случаев избыточна.

Это пускай читают, те кто програм никогда не писал. У меня на столе стоит Атлон ХаРэ 2000+ и я как то не часто замечаю что его производительность избыточна. Даже тот же ворд на серьезных документах тормозит.

VD>>Пока есть только одно неоспоримое преимущество — легкая и быстрая реализация компонентов. Это особо актуально для бизнес-приложений, для остальных же все не так однозначно.
AVK>Так бизнес-приложения это основные деньги. Завоевать рынок платформ для коробочного софта я думаю ни Sun ни MS особо не стремятся.

Ты это MS или Sun-у раскажи. Вот они посмеются... Деньги есть везде. Врочем как и сложные задачи. Среда которая первая займет подовлющее большинство питательных ниш и будет победителем. Это как в стратегиях.

AVK>Ну а основное преимущество джавы и шарпа в скорости разработки.

Скорость разработки на том же VB6 ни чуть не ниже. Есть и другие примеры. Все важно в комплексе.

AVK>К примеру тот же развитый рефлекшн по сути замешает темплейты, естественно ценой быстродействия.

Это разные вещи. К тому же быстродействие и типобезопастность это главные выгоды от генерик-типов.

VD>> А если появятся грамотно реализованные шоблоны, то и этот фиговый листок отпадет за ненадобностью.
AVK>Все это очень неоднозначно. Выиграем тут проиграем там.

Не вот тут вот все будет однозначно. Если конечно не будет сильных побочных эффектов, типа сильного замедления компиляции.

AVK>>>Та же Дельфи, при отсутствии шаблонов, множественного наследования и много чего еще вполне успешно конкурирует с С++.
VD>>Не очень то успешно. Только в одной нише (догадайся в кака?).
AVK>Тем не менее коммерческий успех есть.

Для борланда хватает, но Sun и MS за эти деньги даже пальцем не пошевельнули бы, так что все относитльно. Мы бы думаю были рады даже такому куску.

Здравствуйте VladD2, Вы писали:

AVK>>Да какая нафик разница. Как не называй, суть то одна.
VD>Неразбериха. Вот суть таких именований.
Во всем мире столько беспорядка. Так что приходится мириться. Сперва назвали неудачно, а потом что то менять уже поздно.

AVK>>Это революция не вобще, а по сравнению с предыдущей версией.
VD>Дык если есть версии, то однозначно эволюция. Типа лапки вместо плавников.
Эволюция в целом но революция в частностях.

AVK>>Какой такой? 1.1.6 был вполне применим в коммерческих проектах. Скорость его была конечно же поменьше 1.3, но для многих задач вполне достаточна.

VD>Я о том, что на разницу в двое я глаза еще закрою, но в 10 раз — это уже перебор, а 1.1.х тормозили по черному.
Ну в 10 раз только на очень определенных моментах. Суммарно раза в 1.5-2.

VD>Есть задачи не критичные ко времени, но вом мне все как-то другие попадаются. :(
Time critical задачи нельзя решать ни на тогдашней джаве ни на теперешнем дотнете.

VD>Ну, концептуально нового было мало. В основном более грамотные и абстрактные реализации. Страуструп то тоже Кнута читал. :)
Выше уровень абстракций. А это всегда тяжело дается. Я вспоминаю сейчас конец 80-х начало 90х, когда ООП пошло в массы. Споров по поводу уместности ООП было очень много. Как и споров по поводу событийно-управляемых программ. А там тоже вроде ничего принципиально нового не было.
И еще — я уже не раз говорил, платформы вроде джавы и дотнета проектировались с прицелом не на кодера, а на дизайнера. В этом их принципиальное отличие от языков предыдущего поколения. Сейчас стало возможным пожертвовать эффективностью выполнения в угоду эффективности проектирования. А на старых машинках вроде 286-486 приходилось экономить каждый такт и каждый байт. Потому в свое время языки вроде смоллтолка не получили особого распространения.

AVK>>Рефлекшн джавы не обеспечивает достаточную для реализации визуального программирования функциональность. Там нет способа сказать что тот или иной метод на самом деле property accessor

VD>Ну, это они вроде неплохо и по именам отиличают.
Ну так это и есть java beans. А ты о чем подумал?

VD> В конце концов можно было бы с эмулировать свойства в простых текстовых файлах (все равно их используют).
Классы гибче.

AVK>>Влад, BeanInfo можно вобще не писать для компоненты. Это опциональная вещь. Основа java beans это соглашение об именовании методов доступа к свойствам.
VD>Можно, но за тебя его создадут.
Кто? Я в свое время изучал код Introspector — никто там ничего не создает. Сначала пытаются залезть через рефлекшн. А потом пытаются уже найти BeanInfo. Если не находят отдают то что удалось найти. Более того, можно заставить интроспектора игнорировать BeanInfo.

VD> Главное, что ты не можешь переплюнуть логику компонента реализованного через нестандартные реализации этой лабуды, а занчит обязан все это читать через все эит BeanInfo.
Нет, BeanInfo нужен только дизайнеру. Так что ничего читать ты не обязан. Даже если ты пишешь свой дизайнер то используя интроспектор можешь не обращать внимания на все эти инфы. А можешь написать своего интроспектора который вместо классов будет использовать текстовые файлы.

AVK>>Вот и расскажи как, используя джавовский рефлекшен, это реализовать.

VD>Я с ней не возился, но по описанию они мало чем отличается от Нэтовской.
Ну вобще то отличается (в дотнете оно менее хаотично, но тоже есть что улучшать)

VD>Атрибуты запихиваем в файл. Не очень красиво, но лучше чем паралельное тайп-инофо воротить.
Алгоритм в файл не запихнешь. А потом наследство старой джавы — в plain text не очень то запихнешь, а xml-парсер появился только в 1.4.
А насчет лучше — чем лучше? Хотя бы 1 причину приведи.

AVK>>Влад, в данном случае ты просто не в курсе. BeanInfo это вспомогательные классы.

VD>Насколько я знаю, их можно реализовывать самостоятельно, а значит в объод двигаться нельзя.
Можно. А учитывая то что есть исходники ВСЕЙ библиотеки можно сделать что угодно.

VD> Т.е. даже появление атрибутов не приведет к изменению схемы. Ну, или снова будут гудеть о революции.
Приведет к появлению параллельной. А старую объявят deprecated.

AVK>>To minimize the resources used by a bean, the classes used by bean editors are loaded only when the bean is being edited. They are not needed while the bean is running in an application and therefore not loaded. This information is kept in what's called a bean-info (see BeanInfo).

VD>Ну, и? Нафига все это при наличие крутейшего решлекшона? Ироткр чибы понять, что getXxx и setXxx являются свойствами? Может проще было в этой Яве 2 свойства добавить с делегатами и не выпендриваться пудря мозги про конноы ОО?
Совершенно верно, проще. Но джава не дотнет — у нее уже не первая версия, надо обеспечивать совместимость. Да и не любит Sun менять язык, ох как не любит. И не стал бы его менять если б не MS со своим дотнетом.

VD>>> хотя CODEDOM с его недокументированностью получился тяжеловатым и молопонятным.
AVK>>Вот тут как раз и помогли бы исходники.
VD>Кто бы спрорил. Но лучши исходники и документация. :)
Так на доку надо усилия прикладывать. Встречал в доке к дотнету фразу
This type supports the .NET Framework infrastructure and is not intended to be used directly from your code. ?
Думаешь откуда такое? В джаве подобного нет. Я думаю MS стремился как можно скорее релизнуть этот долгострой, и по причине нехватки времени не написал документацию или не проработал как следует интерфейсы, оставив их проработку на следующие версии.

VD>Дык это и есть главная особенность бобов. Я честно говоря думал Ё-джибя так же сделаны.
Ничего похожего на beaninfo там нет. Все спецификации свойств прописываются в специальном xml файле, который зовется deployment descriptor. Т.е. как раз то что ты предлагал. Вот пример для наглядности (большой потому что из реального приложения, меньше не нашел, а коцать времени нет)

<ejb-jar>
 <enterprise-beans>

  <entity>
   <ejb-name>FirmBean</ejb-name>
   <local-home>ru.khk.ikr.ejb.FirmHome</local-home>
   <local>ru.khk.ikr.ejb.Firm</local>
   <ejb-class>ru.khk.ikr.ejb.FirmBean</ejb-class>

   <prim-key-class>int</prim-key-class>
   <primkey-field>id</primkey-field>
   
   <persistence-type>Container</persistence-type>
   <reentrant>True</reentrant>
   <abstract-schema-name>firms</abstract-schema-name>

   <cmp-field><field-name>id</field-name></cmp-field>
   <cmp-field><field-name>name</field-name></cmp-field>
   <cmp-field><field-name>fullName</field-name></cmp-field>
   <cmp-field><field-name>logo</field-name></cmp-field>

   <query>
    <query-method>
     <method-name>findAll</method-name>
    </query-method>
    <ejb-ql>SELECT o FROM firms o</ejb-ql>
   </query>

  </entity>

  <entity>
   <ejb-name>FirmTabBean</ejb-name>
   <local-home>ru.khk.ikr.ejb.FirmTabHome</local-home>
   <local>ru.khk.ikr.ejb.FirmTab</local>
   <ejb-class>ru.khk.ikr.ejb.FirmTabBean</ejb-class>

   <prim-key-class>int</prim-key-class>
   <primkey-field>id</primkey-field>
   
   <persistence-type>Container</persistence-type>
   <reentrant>True</reentrant>
   <abstract-schema-name>firmtabs</abstract-schema-name>

   <cmp-field><field-name>id</field-name></cmp-field>
   <cmp-field><field-name>name</field-name></cmp-field>
   <cmp-field><field-name>content</field-name></cmp-field>
   <cmp-field><field-name>contentType</field-name></cmp-field>
   <cmp-field><field-name>orderNum</field-name></cmp-field>

  </entity>

  <entity>
   <ejb-name>GoodBean</ejb-name>
   <local-home>ru.khk.ikr.ejb.GoodHome</local-home>
   <local>ru.khk.ikr.ejb.Good</local>
   <ejb-class>ru.khk.ikr.ejb.GoodBean</ejb-class>

   <prim-key-class>int</prim-key-class>
   <primkey-field>id</primkey-field>
   
   <persistence-type>Container</persistence-type>
   <reentrant>True</reentrant>
   <abstract-schema-name>goods</abstract-schema-name>

   <cmp-field><field-name>id</field-name></cmp-field>
   <cmp-field><field-name>name</field-name></cmp-field>
   <cmp-field><field-name>price</field-name></cmp-field>
  </entity>

  <entity>
   <ejb-name>GoodGroupBean</ejb-name>
   <local-home>ru.khk.ikr.ejb.GoodGroupHome</local-home>
   <local>ru.khk.ikr.ejb.GoodGroup</local>
   <ejb-class>ru.khk.ikr.ejb.GoodGroupBean</ejb-class>

   <prim-key-class>int</prim-key-class>
   <primkey-field>id</primkey-field>
   
   <persistence-type>Container</persistence-type>
   <reentrant>True</reentrant>
   <abstract-schema-name>goodgroups</abstract-schema-name>

   <cmp-field><field-name>id</field-name></cmp-field>
   <cmp-field><field-name>name</field-name></cmp-field>

   <query>
    <query-method>
     <method-name>findFirmRoot</method-name>
    </query-method>
    <ejb-ql>SELECT o FROM goodgroups o WHERE (o.firm = ?1)AND(o.parent.id = -1)</ejb-ql>
   </query>
  </entity>

 </enterprise-beans>

 <relationships>
  <ejb-relation>
   <ejb-relationship-role>
    <relationship-role-source>
     <ejb-name>FirmTabBean</ejb-name>
    </relationship-role-source>
    <cmr-field>
     <cmr-field-name>firm</cmr-field-name>
    </cmr-field>
   </ejb-relationship-role>

   <ejb-relationship-role>
    <relationship-role-source>
     <ejb-name>FirmBean</ejb-name>
    </relationship-role-source>

    <cmr-field>
     <cmr-field-name>firmTabList</cmr-field-name>
    </cmr-field>
   </ejb-relationship-role>
  </ejb-relation>

  <ejb-relation>
   <ejb-relationship-role>
    <relationship-role-source>
     <ejb-name>GoodGroupBean</ejb-name>
    </relationship-role-source>

    <cmr-field>
     <cmr-field-name>firm</cmr-field-name>
    </cmr-field>

    <multiplicity>Many</multiplicity>
   </ejb-relationship-role>

   <ejb-relationship-role>
    <relationship-role-source>
     <ejb-name>FirmBean</ejb-name>
    </relationship-role-source>

    <multiplicity>One</multiplicity>
   </ejb-relationship-role>
  </ejb-relation>

  <ejb-relation>
   <ejb-relationship-role>
    <relationship-role-source>
     <ejb-name>GoodGroupBean</ejb-name>
    </relationship-role-source>
    <cmr-field>
     <cmr-field-name>parent</cmr-field-name>
    </cmr-field>
   </ejb-relationship-role>

   <ejb-relationship-role>
    <relationship-role-source>
     <ejb-name>GoodGroupBean</ejb-name>
    </relationship-role-source>

    <cmr-field>
     <cmr-field-name>childList</cmr-field-name>
    </cmr-field>
   </ejb-relationship-role>
  </ejb-relation>

  <ejb-relation>
   <ejb-relationship-role>
    <relationship-role-source>
     <ejb-name>GoodBean</ejb-name>
    </relationship-role-source>
    <cmr-field>
     <cmr-field-name>goodGroup</cmr-field-name>
    </cmr-field>
   </ejb-relationship-role>

   <ejb-relationship-role>
    <relationship-role-source>
     <ejb-name>GoodGroupBean</ejb-name>
    </relationship-role-source>

    <cmr-field>
     <cmr-field-name>goodList</cmr-field-name>
    </cmr-field>
   </ejb-relationship-role>
  </ejb-relation>
</relationships>

</ejb-jar>

Я думаю это потому что EJB моложе java beans.

AVK>>Влад, ты просто не в курсе.

VD>Я в курсе, что есть дефолтная реализация.
Кого? BeanInfo? Нэту. Есть дефолтовые реализации property editor.

VD>>>В Нэте тоже ввели интерфейс, но он вообще ничего не делает.
AVK>>Какой интерфейс?
VD>IComponent
Ну почему же он ничего не делает? Он обеспечивает помощение Component в Container. Плюс является неким флажком указывающим что это компонент.

VD>Я честно говоря считаю, что это тоже ошибка. Любой класс должен быть компонентом если это позволяет система. В Нэт и Яве это возможно, но не реализовано. :( Причем в Яве худшая форма.
Излишняя функциональность. Не всегда оно нужно.

VD>>>Эээ... батенька. Нэт обходтися без ненужных примочек. Есть пути порулить, но они опциональные.
AVK>>Ну так BeanInfo и PropertyEditor тоже опциональные.

VD>Не, ты не можешь ралботать с бинам через рефлекшон, так как найдется один боб который не будет соотвествовать своему описанию.
А тебе и не надо работать. Есть интроспектор, он за тебя все выяснит и преподнесет тебе результат на блюдечке, вне зависимости от того наличествует ли beaninfo или нет его и никогда не было.

AVK>>В джаве все точно так же.

VD>Нет, в Яве по умолчанию создается умолчальная реализация всех этих BeanInfo и Introspector-ов, а уже она лезит к компонентам.
Нет. Никакой реализации по умолчанию не создается. А интроспектор вобще синглтон. Я это точно знаю потому что в свое время ковырялся в исходниках интроспектора и точно знаю как он работает. Если хочешь вышлю тебе его исходник, сам посмотришь.

VD>Получается явная замена рефлекшона. Ольтернатива для получения информации о типах.
Не альтернатива а недоделанность рефлекшена, не позволяющая его методами получить нужную информацию. Атрибуты были бы уместнее, но Sun до них не додумался. Теперь додумается :)

AVK>>А его и нет, выделенного класса. Есть только интерфейсы. А базовые классы для EJB у каждого сервера свои. EJB вобще больше похожи на aspx чем на классы как таковые.
VD>Класное достижение!
Чем тебе не нравиться? Там все очень иначе. Долго объяснять.

AVK>>Где то в инете видел исследование — производительность современных компьютеров в 95% случаев избыточна.
VD>Это пускай читают, те кто програм никогда не писал. У меня на столе стоит Атлон ХаРэ 2000+ и я как то не часто замечаю что его производительность избыточна. Даже тот же ворд на серьезных документах тормозит.
У меня вот на работе Cel1000 не особо то тормозит. Видимо у тебя задачи такие. А ворд тормозит совсем по другой причине. Я думаю на офисе MS оправдывает свою репутацию. :(

VD>Ты это MS или Sun-у раскажи. :) Вот они посмеются... Деньги есть везде.
Сколько контор в штуках производит коробочный софт? Я думаю не очень много.

VD>Врочем как и сложные задачи. Среда которая первая займет подовлющее большинство питательных ниш и будет победителем. Это как в стратегиях.
Нельзя объять необъятное. Тебе достанется некий кусок рынка. И нужно выбрать оптимум чтобы сектор был с одной стороны достаточно велик чтобы приносить большие деньги но с другой стороны достаточно мал чтобы хватило сил его завоевать и удержать.

VD>Скорость разработки на том же VB6 ни чуть не ниже. Есть и другие примеры. Все важно в комплексе.
Скорость проектирования и качество полученных решений ниже. Качество я имею ввиду в плане дальнейшего развития.

AVK>>К примеру тот же развитый рефлекшн по сути замешает темплейты, естественно ценой быстродействия.
VD>Это разные вещи.
Тем не менее функционал темплейтов через рефлекшн реализуем.

VD>К тому же быстродействие и типобезопастность это главные выгоды от генерик-типов.
Типобезовасность реализуема и без них. А вот быстродействие таки да — ощутимо больше полиморфной.

VD>Не вот тут вот все будет однозначно. Если конечно не будет сильных побочных эффектов, типа сильного замедления компиляции.
А что будет с GC? С рефлекшеном? С сериализацией? С ремоутингом? Когда начинаешь думать о деталях становится страшно.

Здравствуйте VladD2, Вы писали:

VD>Ты главное от MS пресрелизы не читай, а то вон IT уже почти убедил себя, что кроме Web-сервисов в программировании ничего путного нет, а любую RPC-технологию можно замедлить до их скорости.

Но, но, но! Я папрашу!
Я заменял, заменяю и буду заменять все комы, которые только можно, на web-сервисы. У меня проблем с их скоростями нету, надо будет ещё пару процессоров в сервер воткнём. А вот deployment меня волнует серьёзно. После каждого изменения COM-объекта перегружать сотни рабочих станций мне никто не позволит. С remoting на клиентах тоже пока сильно не разбежишься, так что получается, что пока WS — спасение от всех зол.