Народ -а в чем фан в C#.
Вот написал пару приложний — все слизали с JAVA...
Многоплатформенности нет так как нет платформ поддерживающих .NET реально.
Я бы сказал C# = JAVA for Windows... в чем фан то....
17.05.04 13:03: Перенесено модератором из '.NET' — TK
Здравствуйте shmakov, Вы писали:
S>Народ -а в чем фан в C#. S>Вот написал пару приложний — все слизали с JAVA... S>Многоплатформенности нет так как нет платформ поддерживающих .NET реально. S>Я бы сказал C# = JAVA for Windows... в чем фан то...
Хотя доходит... так проще под винды писать хотя как то трагично... елки зеленые — так этим же борланд занимался — просто и для виндов....
Здравствуйте shmakov, Вы писали:
S>Народ -а в чем фан в C#. S>Вот написал пару приложний — все слизали с JAVA... S>Многоплатформенности нет так как нет платформ поддерживающих .NET реально. S>Я бы сказал C# = JAVA for Windows... в чем фан то....
1. Самое главное, что это не вещь в себе, как Java, а дальнейшее развитие Win платформы. Можно спокойно использовать в одном проекте, как старый код написанный на C/C++, так и даже при написании новых проектов критические части кода можно написать на C++/ассемблере.
2. Аттрибуты
3. Конкуренция. У Java появился достойный приемник, так что Sun может зашевелится и родит что-нибудь новое.
Может быть... я вообще на JAVA пишу -как то разницы не заметил. Так ради тренеровки навоял простенький клиент-сервер на C#. Что же... если за это будут платить буду писать и на этом добре . Хотя я уже давно понял — на чем бы не писать, какая разница, все одно while...for...if... )
Здравствуйте DarkGray, Вы писали:
DG>Здравствуйте shmakov, Вы писали:
S>>Народ -а в чем фан в C#. S>>Вот написал пару приложний — все слизали с JAVA... S>>Многоплатформенности нет так как нет платформ поддерживающих .NET реально. S>>Я бы сказал C# = JAVA for Windows... в чем фан то....
DG>1. Самое главное, что это не вещь в себе, как Java, а дальнейшее развитие Win платформы. Можно спокойно использовать в одном проекте, как старый код написанный на C/C++, так и даже при написании новых проектов критические части кода можно написать на C++/ассемблере.
DG>2. Аттрибуты
DG>3. Конкуренция. У Java появился достойный приемник, так что Sun может зашевелится и родит что-нибудь новое.
Здравствуйте shmakov, Вы писали:
S>Народ -а в чем фан в C#. S>Вот написал пару приложний — все слизали с JAVA... S>Многоплатформенности нет так как нет платформ поддерживающих .NET реально. S>Я бы сказал C# = JAVA for Windows... в чем фан то....
Всего: 36.92Mb -- вот сколько счастья для обычного пользователя!!!! :)))
Аналогичное, но кросс-платформенное решение:
Sun Java Runtime Environment Java2 Standard Edition (v 1.4.0_01) (размер 11.6Mb): http://java.sun.com/j2se/1.4/download.html
Всего: 11.6Mb -- меньше счастья для обычного пользователя...:(
:)))
Здравствуйте iZEN, Вы писали:
ZEN>Всего: 11.6Mb -- меньше счастья для обычного пользователя... ZEN>
Я уже говорил .Net Redistributable это несколько больше нежели JRE.
И я честно говоря не понял — зачем одновременно MDAC 2.7 и SP2 к 2.6. Что ты этим сказать хотел?
Здравствуйте AndrewVK, Вы писали:
AVK>Здравствуйте iZEN, Вы писали:
ZEN>>Всего: 11.6Mb -- меньше счастья для обычного пользователя...:( ZEN>> :)))
AVK>Я уже говорил .Net Redistributable это несколько больше нежели JRE.
Чем больше?
AVK>И я честно говоря не понял — зачем одновременно MDAC 2.7 и SP2 к 2.6. Что ты этим сказать хотел?
Если можете обойтись одним MDAC 2.7, то флаг Вам в руки (некоторые не могут из-за различных версий Win/SQLServer), тогда:
36.9-5.04=31.86 -- счастья поубавилось, но не сильно. ;)
Здравствуйте iZEN, Вы писали:
S>>Я бы сказал C# = JAVA for Windows... в чем фан то....
ZEN>Счастье есть, его не может не быть.
Счастье есть, оно не может не есть.
ZEN>Всего: 11.6Mb -- меньше счастья для обычного пользователя...
Т.е. ты считаешь в мегобайтах? Ну-ну.
Во-первых, неправильно считаешь в обоих случаях.
Во-вторых, разница для 10 или 30 М на винте размером в 40 гиг, не будет видна даже в микроскоп.
В-третьих, выкачать из современного интернета первое нужно 1 минута, второе — 3. Из несовременного — запаришься качать и то и другое.
В-четвётых, а давай сравнивать не в мегобайтах, а в языках программирования. Java — это "Java, Sun Java" (c) Дж. Бонд. К .NET только от MS прилагаются C#, VB, MC++, JScript, Java (!!!). Плюс уже есть с полтора десятка языков от всяких левых производителей. Поэтому, я запросто стогу писать под .NET на Java, а вот сможешь ли ты писать под Java на C#?
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте IT, Вы писали:
IT>Здравствуйте iZEN, Вы писали:
S>>>Я бы сказал C# = JAVA for Windows... в чем фан то....
ZEN>>Счастье есть, его не может не быть.
IT>Счастье есть, оно не может не есть. ;)
ZEN>>Всего: 11.6Mb -- меньше счастья для обычного пользователя...:(
IT>Т.е. ты считаешь в мегобайтах? Ну-ну. IT>Во-первых, неправильно считаешь в обоих случаях.
Я считаю: меньше размер -- меньше потенциальных ошибок в коде.
Слышали, наверное, о "рекорде" "ServicePack для WindowsXP будет весить 600Мб" -- насколько это сопоставимо с размером самой системы?
IT>Во-вторых, разница для 10 или 30 М на винте размером в 40 гиг, не будет видна даже в микроскоп.
Так чем же по функциональности .Net опережает Java. Чего такого нельзя написать на Java, но можно в .Net? Именно в функциональном плане.
IT>В-третьих, выкачать из современного интернета первое нужно 1 минута, второе — 3. Из несовременного — запаришься качать и то и другое.
Чем "современный интернет" отличается от "современного", выделенкой что-ли? У меня модемная линия порой быстрее и стабильнее выделенки...:) Повезло во второй раз...
IT>В-четвётых, а давай сравнивать не в мегобайтах, а в языках программирования. Java — это "Java, Sun Java" (c) Дж. Бонд. К .NET только от MS прилагаются C#, VB, MC++, JScript, Java (!!!). Плюс уже есть с полтора десятка языков от всяких левых производителей. Поэтому, я запросто стогу писать под .NET на Java, а вот сможешь ли ты писать под Java на C#? :)))
Читали притчу о Вавилонской башне? Почему её не могли построить, знаете?
В одной голове несколько языков -- обалдеть можно! Либо один, но отлично, либо много, но удовлетворительно. Есть что изучать до старости... :))
Здравствуйте Аноним, Вы писали:
А>Здравствуйте AndrewVK, Вы писали:
AVK>>Здравствуйте iZEN, Вы писали:
ZEN>>>Всего: 11.6Mb -- меньше счастья для обычного пользователя... ZEN>>>
AVK>>Я уже говорил .Net Redistributable это несколько больше нежели JRE.
А>Чем больше?
1) Компиляторы. В JRE их нет.
2) Некоторые библиотеки, аналоги которых в J2EE. Например System.Web.Mail. Да и вобще аналог System.Web.* в JRE отсутствует.
Xml (в 1.4 правда наконец то включили, но xslt там нет, только dom и sax). Web Services наконец.
Короче, подводя итог, .Net Redistributable достаточен для развертывания web-приложений, а вот для развертывания web-приложений на java нужно
Здравствуйте AndrewVK, Вы писали:
AVK>Здравствуйте Аноним, Вы писали:
А>>Здравствуйте AndrewVK, Вы писали:
AVK>>>Здравствуйте iZEN, Вы писали:
ZEN>>>>Всего: 11.6Mb -- меньше счастья для обычного пользователя...:( ZEN>>>> :)))
AVK>>>Я уже говорил .Net Redistributable это несколько больше нежели JRE.
А>>Чем больше? AVK>1) Компиляторы. В JRE их нет.
Зачем компиляторы конечному пользователю? Что он собирается перекомпилировать?
AVK>2) Некоторые библиотеки, аналоги которых в J2EE. Например System.Web.Mail. Да и вобще аналог System.Web.* в JRE отсутствует.
Есть отдельная библиотека JavaMail, которую используют разработчики и включают необходимые классы в клиентское приложение, работающее в JRE.
AVK>Xml (в 1.4 правда наконец то включили, но xslt там нет, только dom и sax). Web Services наконец.
xslt -- это серверная часть(!), по большому счёту на клиенте не нужна.
AVK>Короче, подводя итог, .Net Redistributable достаточен для развертывания web-приложений
Для клиента оно слишком наворочено, многие функции не нужны. Для сервера слишком мало, многих функций нет.
AVK>, а вот для развертывания web-приложений на java нужно AVK>1) J2SE SDK 1.4 — 37М AVK>2) J2EE SDK 1.3.1 — 17М
Кхех...вы бы ещё про MSDN для .Net вспомнили, без него как без рук.
Не путайте, на клиенте это не необходимо.
AVK>Итого 54М. Вот такие вот пирожки с котятами.э
Для Java-сервера в самый раз.
А сколько всего нужно для .Net-сервера? Вы заплатки для IIS/MSIE и их версии считали?
Здравствуйте iZEN, Вы писали:
AVK>>1) Компиляторы. В JRE их нет. ZEN>Зачем компиляторы конечному пользователю? Что он собирается перекомпилировать?
ASP, JSP
AVK>>2) Некоторые библиотеки, аналоги которых в J2EE. Например System.Web.Mail. Да и вобще аналог System.Web.* в JRE отсутствует. ZEN>Есть отдельная библиотека JavaMail, которую используют разработчики и включают необходимые классы в клиентское приложение, работающее в JRE.
Которая входит в J2EE. И скачать ее отдельно низзя. А в .Net тоже можно библиотечки покоцать.
AVK>>Xml (в 1.4 правда наконец то включили, но xslt там нет, только dom и sax). Web Services наконец. ZEN>xslt -- это серверная часть(!), по большому счёту на клиенте не нужна.
Очень спорное утверждение. Изначально это как раз клиентская технология, просто ввиду недостаточной распространенности стандарта приходится делать преобразование на сервере.
AVK>>Короче, подводя итог, .Net Redistributable достаточен для развертывания web-приложений ZEN>Для клиента оно слишком наворочено, многие функции не нужны. Для сервера слишком мало, многих функций нет.
Во как. А сервера что? Уже не люди? И ты знаешь сколько джавы на клиенте? В настоящее время это очень серверная платформа. И вот тут непонятно — платформа, 90% применений которой сервера распространяется без серверных библиотек.
AVK>>, а вот для развертывания web-приложений на java нужно AVK>>1) J2SE SDK 1.4 — 37М AVK>>2) J2EE SDK 1.3.1 — 17М
ZEN>Кхех...вы бы ещё про MSDN для .Net вспомнили, без него как без рук.
Ок. Тогда ты к джаве еще документацию приплюсуй. В SDK документации нет. Ее отдельно качать надо.
ZEN>Не путайте, на клиенте это не необходимо.
А на сервере необходимо. Что дальше?
AVK>>Итого 54М. Вот такие вот пирожки с котятами.э
ZEN>Для Java-сервера в самый раз.
Да ну? Я тут еще всяких томкетов не вспоминаю. ZEN>А сколько всего нужно для .Net-сервера?
.Net Redist достаточно. А SQL и Web сервер для обоих нужен.
ZEN>Вы заплатки для IIS/MSIE и их версии считали?
MSIE это сугубо серверный софт . И при чем здесь заплатки? Их что — для томкета с апачей меньше надо?
Здравствуйте iZEN, Вы писали:
IT>>Т.е. ты считаешь в мегобайтах? Ну-ну. IT>>Во-первых, неправильно считаешь в обоих случаях.
ZEN>Я считаю: меньше размер -- меньше потенциальных ошибок в коде.
Самый маленький размер кода получится если писать на ассемблере, без макросов. Следуя твоей логике — если всю библиотеку дотнета переписать на ассемблере потенциальных ошибок в ней будет меньше?
ZEN>Слышали, наверное, о "рекорде" "ServicePack для WindowsXP будет весить 600Мб" -- насколько это сопоставимо с размером самой системы?
А при чем здесь дотнет и джава?
IT>>Во-вторых, разница для 10 или 30 М на винте размером в 40 гиг, не будет видна даже в микроскоп.
ZEN>Так чем же по функциональности .Net опережает Java. Чего такого нельзя написать на Java, но можно в .Net? Именно в функциональном плане.
Чего такого нельзя написать на ассемблере что можно написать на джава? Так чем же по функциональности джава опережает ассемблер?
Как, еще ущербность своей логики не чувствуешь?
IT>>В-третьих, выкачать из современного интернета первое нужно 1 минута, второе — 3. Из несовременного — запаришься качать и то и другое.
ZEN>Чем "современный интернет" отличается от "современного", выделенкой что-ли?
Скоростью.
ZEN>У меня модемная линия порой быстрее и стабильнее выделенки... Повезло во второй раз...
А у меня мобилка на пальма качает 4К в секунду. А на работе 256К. А у бужуев диалап составляет очень маленький процент. Что из этого следует?
ZEN>Читали притчу о Вавилонской башне? Почему её не могли построить, знаете? ZEN>В одной голове несколько языков -- обалдеть можно! Либо один, но отлично, либо много, но удовлетворительно. Есть что изучать до старости...
Вавилонскую башню недостроили потому что люди перестали понимать чужие языки. А в дотнете языки вполне друг друга понимают.
Здравствуйте AndrewVK, Вы писали:
AVK>Здравствуйте iZEN, Вы писали:
AVK>>>1) Компиляторы. В JRE их нет. ZEN>>Зачем компиляторы конечному пользователю? Что он собирается перекомпилировать? AVK>ASP, JSP
Да бросьте вы! ASP и JSP -- это серверная часть работы, но никак не клиентская.
AVK>>>2) Некоторые библиотеки, аналоги которых в J2EE. Например System.Web.Mail. Да и вобще аналог System.Web.* в JRE отсутствует. ZEN>>Есть отдельная библиотека JavaMail, которую используют разработчики и включают необходимые классы в клиентское приложение, работающее в JRE.
AVK>Которая входит в J2EE. И скачать ее отдельно низзя.
Кто вам такое сказал? :)
AVK>А в .Net тоже можно библиотечки покоцать.
С боьшим г...мором.
AVK>>>Xml (в 1.4 правда наконец то включили, но xslt там нет, только dom и sax). Web Services наконец. ZEN>>xslt -- это серверная часть(!), по большому счёту на клиенте не нужна. AVK>Очень спорное утверждение. Изначально это как раз клиентская технология, просто ввиду недостаточной распространенности стандарта приходится делать преобразование на сервере.
Цитата http://java.sun.com/j2se/1.4/datasheet.1_4.html:
"J2SE version 1.4 includes the basic facilities for working with XML documents, and provides built-in support for XML standards such as SAX 1.0 and 2.0, DOM 1.0 and 2.0, and XSLT support."
AVK>>>Короче, подводя итог, .Net Redistributable достаточен для развертывания web-приложений ZEN>>Для клиента оно слишком наворочено, многие функции не нужны. Для сервера слишком мало, многих функций нет. AVK>Во как. А сервера что? Уже не люди? И ты знаешь сколько джавы на клиенте? В настоящее время это очень серверная платформа. И вот тут непонятно — платформа, 90% применений которой сервера распространяется без серверных библиотек.
J2EE -- серверные библиотеки там.
AVK>>>, а вот для развертывания web-приложений на java нужно AVK>>>1) J2SE SDK 1.4 — 37М AVK>>>2) J2EE SDK 1.3.1 — 17М
ZEN>>Кхех...вы бы ещё про MSDN для .Net вспомнили, без него как без рук. AVK>Ок. Тогда ты к джаве еще документацию приплюсуй. В SDK документации нет. Ее отдельно качать надо.
SDK -- это средство разработки, документация нужна программисту. Но не в таких(MSDN) количествах! Или в таких? ;)
ZEN>>Не путайте, на клиенте это не необходимо. AVK>А на сервере необходимо. Что дальше?
AVK>>>Итого 54М. Вот такие вот пирожки с котятами.э ZEN>>Для Java-сервера в самый раз. AVK>Да ну? Я тут еще всяких томкетов не вспоминаю.
Не путайте сервер приложений, сервер web-контента и среду исполнения.
Хотя у вас другого мнения быть не может и выхода нет -- интеграция всего и вся(Windows+IIS+COM++ASP.Net+.Net+...+MSIE+MSOffice+...+интегрированный_поиск_в_интернете_который_вешает_систему+Оутглюк_который полон дыр), блин. Всё друг на друга повязано, друг другом управляет, круговая порука(проруха), одним словом.
ZEN>>А сколько всего нужно для .Net-сервера? AVK>.Net Redist достаточно. А SQL и Web сервер для обоих нужен.
Ещё бы: IIS интегрирован в систему (Win2K, WinXP), везде есть. Неочем голове болеть. Главное -- вовремя качать патчи. :)
ZEN>>Вы заплатки для IIS/MSIE и их версии считали? AVK>MSIE это сугубо серверный софт :). И при чем здесь заплатки? Их что — для томкета с апачей меньше надо?
Да уж, всё смешалось в этом мире...и MSIE на сервере есть, как ни странно, и работает ведь иногда. :))
Как известно, качество заплаток в их своевременном обнаружении и установке. :)
Но главное совсем не в них, а в открытости и доступности продуктов, где можно отследить ошибки всем миром. :user:
Здравствуйте IT, Вы писали:
IT>Здравствуйте iZEN, Вы писали:
S>>>Я бы сказал C# = JAVA for Windows... в чем фан то....
ZEN>>Счастье есть, его не может не быть.
IT>Счастье есть, оно не может не есть. ;)
ZEN>>Всего: 11.6Mb -- меньше счастья для обычного пользователя...:(
IT>Т.е. ты считаешь в мегобайтах? Ну-ну. IT>Во-первых, неправильно считаешь в обоих случаях. IT>Во-вторых, разница для 10 или 30 М на винте размером в 40 гиг, не будет видна даже в микроскоп. IT>В-третьих, выкачать из современного интернета первое нужно 1 минута, второе — 3. Из несовременного — запаришься качать и то и другое.
Почему же второе [JRE] качать дольше чем .Net Redist? Ведь весит раза в три меньше.
IT>В-четвётых, а давай сравнивать не в мегобайтах, а в языках программирования. Java — это "Java, Sun Java" (c) Дж. Бонд.
Цитатка: "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
Здравствуйте Аноним, Вы писали:
AVK>>>>1) Компиляторы. В JRE их нет. ZEN>>>Зачем компиляторы конечному пользователю? Что он собирается перекомпилировать? AVK>>ASP, JSP А>Да бросьте вы! ASP и JSP -- это серверная часть работы, но никак не клиентская.
Да, серверная. Ну и что?
AVK>>>>2) Некоторые библиотеки, аналоги которых в J2EE. Например System.Web.Mail. Да и вобще аналог System.Web.* в JRE отсутствует. ZEN>>>Есть отдельная библиотека JavaMail, которую используют разработчики и включают необходимые классы в клиентское приложение, работающее в JRE.
AVK>>Которая входит в J2EE. И скачать ее отдельно низзя.
А>Кто вам такое сказал?
На java.sun.com отдельно она не лежит, поскольку javax.mail входит в состав J2EE и выкачивается
вместе с ним.
AVK>>Очень спорное утверждение. Изначально это как раз клиентская технология, просто ввиду недостаточной распространенности стандарта приходится делать преобразование на сервере.
AVK>>Во как. А сервера что? Уже не люди? И ты знаешь сколько джавы на клиенте? В настоящее время это очень серверная платформа. И вот тут непонятно — платформа, 90% применений которой сервера распространяется без серверных библиотек. А>J2EE -- серверные библиотеки там.
Ну так я и посчитал J2SE+J2EE.
ZEN>>>Кхех...вы бы ещё про MSDN для .Net вспомнили, без него как без рук. AVK>>Ок. Тогда ты к джаве еще документацию приплюсуй. В SDK документации нет. Ее отдельно качать надо.
А>SDK -- это средство разработки, документация нужна программисту.
Но не в таких(MSDN) количествах! Или в таких?
Ты сам предложил MSDN приплюсовать. Я что то не пойму тебя никак —
для дотнета документация нужна для работы, а для джава только программисту, ты это имеешь ввиду?
А>Не путайте сервер приложений, сервер web-контента и среду исполнения.
Я не путаю — это ты чего то путаешь постоянно.
А>Хотя у вас другого мнения быть не может и выхода нет -- интеграция всего и вся
(Windows
джава уже без ОС научилась работать?
А>IIS
Это компонент Windows
А>+COM
Это компонент Windows, причем неотемлемый. Впрочем для веб-сервера COM не нужен.
А>++ASP.Net
Входит в состав .Net Redist. В отличие от.
А>+.Net
Это технология а не продукт. Так что совсем не к месту.
А>+...+MSIE
Не нужен
А>+MSOffice
Не нужен
А>+...+интегрированный_поиск_в_интернете_который_вешает_систему
По желанию
А>+Оутглюк_который полон дыр),
Не нужен
ZEN>>>А сколько всего нужно для .Net-сервера? AVK>>.Net Redist достаточно. А SQL и Web сервер для обоих нужен.
А>Ещё бы: IIS интегрирован в систему (Win2K, WinXP), везде есть. Неочем голове болеть. Главное -- вовремя качать патчи.
Апач тоже в линуха интегрирован. Главное вовремя качать свежие версии.
Я чего то не пойму — ты чего доказать пытаешся? Тебе шашечки или ехать?
ZEN>>>Вы заплатки для IIS/MSIE и их версии считали? AVK>>MSIE это сугубо серверный софт . И при чем здесь заплатки? Их что — для томкета с апачей меньше надо? А>Да уж, всё смешалось в этом мире...и MSIE на сервере есть, как ни странно, и работает ведь иногда.
Объясни внятно — зачем на сервере ставить заплатки для MSIE?
А>Как известно, качество заплаток в их своевременном обнаружении и установке. А>Но главное совсем не в них, а в открытости и доступности продуктов, где можно отследить ошибки всем миром.
Я вот никак не пойму — при чем здесь дотнет то? Исходники CLI лежат, бери не хочу.
Здравствуйте AndrewVK, Вы писали:
AVK>Здравствуйте iZEN, Вы писали:
IT>>>Т.е. ты считаешь в мегобайтах? Ну-ну. IT>>>Во-первых, неправильно считаешь в обоих случаях.
ZEN>>Я считаю: меньше размер -- меньше потенциальных ошибок в коде. AVK>Самый маленький размер кода получится если писать на ассемблере, без макросов. Следуя твоей логике — если всю библиотеку дотнета переписать на ассемблере потенциальных ошибок в ней будет меньше?
Не в этом дело. Я говорил про ассемблер?
Да, вы перепишите dotNet на C++ по своему вкусу и исправьте ошибки. Слабо? :))) Надеюсь, у вас получится наименьший размер кода.
ZEN>>Слышали, наверное, о "рекорде" "ServicePack для WindowsXP будет весить 600Мб" -- насколько это сопоставимо с размером самой системы? AVK>А при чем здесь дотнет и джава?
Одного поля ягоды. Одной конторы продукты жизнедеятельности.
IT>>>Во-вторых, разница для 10 или 30 М на винте размером в 40 гиг, не будет видна даже в микроскоп.
ZEN>>Так чем же по функциональности .Net опережает Java. Чего такого нельзя написать на Java, но можно в .Net? Именно в функциональном плане. AVK>Чего такого нельзя написать на ассемблере что можно написать на джава? Так чем же по функциональности джава опережает ассемблер? AVK>Как, еще ущербность своей логики не чувствуешь?
Это ваша логика, я про ассемблер не говорил. :) Не так ли? Так что объясняйте сами себе диалектику противоречий.
IT>>>В-третьих, выкачать из современного интернета первое нужно 1 минута, второе — 3. Из несовременного — запаришься качать и то и другое.
ZEN>>Чем "современный интернет" отличается от "современного", выделенкой что-ли? AVK>Скоростью.
Да знаю я, чем всё это отличается.
ZEN>>У меня модемная линия порой быстрее и стабильнее выделенки...:) Повезло во второй раз... AVK>А у меня мобилка на пальма качает 4К в секунду. А на работе 256К. А у бужуев диалап составляет очень маленький процент. Что из этого следует?
Пользуйтесь выделенкой где только можно, даже в метро.
ZEN>>Читали притчу о Вавилонской башне? Почему её не могли построить, знаете? ZEN>>В одной голове несколько языков -- обалдеть можно! Либо один, но отлично, либо много, но удовлетворительно. Есть что изучать до старости... :)) 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...
А ты почитай на досуге лицензию к J2EE — почерпнешь для себя много удивительного. В частности по поводу возможности выкладывать исходники EJB сервера если он носит гордое имя J2EE compatible.
Здравствуйте iZEN, Вы писали:
ZEN>Я считаю: меньше размер -- меньше потенциальных ошибок в коде. ZEN>Слышали, наверное, о "рекорде" "ServicePack для WindowsXP будет весить 600Мб" -- насколько это сопоставимо с размером самой системы?
Дык, я тут Линукс какой-то видел на 3-х копмактах, что ж теперь считать, что по сравнению с Windows там просто два диска глюков? :???:
Может посмотреть какая в данном объёме функциональность? Я не думаю, что в 10 M явовских библиотек есть что-то большее, чем выполнение аплетов в браузере.
ZEN>Так чем же по функциональности .Net опережает Java. Чего такого нельзя написать на Java, но можно в .Net? Именно в функциональном плане.
А это тут причём?
ZEN>Чем "современный интернет" отличается от "современного", выделенкой что-ли? У меня модемная линия порой быстрее и стабильнее выделенки...:) Повезло во второй раз...
У меня вообще нет модемных линий, ни дома ни на работе, надеюсь, что скоро и у вас их не будет. Именно поэтому, разница в объёме занимаемого дистрибутива между Java и .NET не имеет абсолютно никакого значения и не может служить аргументом. Вот функциональность — да.
ZEN>Читали притчу о Вавилонской башне? Почему её не могли построить, знаете?
Ой, да ладно. Скажи ещё что им просто Java от Sun не хватило, а так бы всё было пучком :)))
ZEN>В одной голове несколько языков -- обалдеть можно! Либо один, но отлично, либо много, но удовлетворительно. Есть что изучать до старости... :))
Да уж, приходиться пользовать каждый день как минимум — C++, C#, VB, JScript, T-SQL, XML, HTML, русский, английский :) Не представляю как всё это можно заменить одной Java :))
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте iZEN, Вы писали:
ZEN>>>Я считаю: меньше размер -- меньше потенциальных ошибок в коде. AVK>>Самый маленький размер кода получится если писать на ассемблере, без макросов. Следуя твоей логике — если всю библиотеку дотнета переписать на ассемблере потенциальных ошибок в ней будет меньше?
ZEN>Не в этом дело. Я говорил про ассемблер?
Я просто следую твоей логике — "меньше размер -- меньше потенциальных ошибок в коде"
ZEN>Да, вы перепишите dotNet на C++ по своему вкусу и исправьте ошибки. Слабо? Надеюсь, у вас получится наименьший размер кода.
А зачем? Это тебе наименьший размер необходим. Мне на современных 40-120 гиг винтах +-100М не колышут.
ZEN>>>Слышали, наверное, о "рекорде" "ServicePack для WindowsXP будет весить 600Мб" -- насколько это сопоставимо с размером самой системы? AVK>>А при чем здесь дотнет и джава? ZEN>Одного поля ягоды. Одной конторы продукты жизнедеятельности.
В MS очень много практически независимых команд разработчиков. Так что давай мух отдельно а котлеты отдельно.
ZEN>>>Так чем же по функциональности .Net опережает Java. Чего такого нельзя написать на Java, но можно в .Net? Именно в функциональном плане. AVK>>Чего такого нельзя написать на ассемблере что можно написать на джава? Так чем же по функциональности джава опережает ассемблер? AVK>>Как, еще ущербность своей логики не чувствуешь? ZEN>Это ваша логика, я про ассемблер не говорил. Не так ли? Так что объясняйте сами себе диалектику противоречий.
Ты не уходи от темы. Я просто логически продолжил твою мысль. Это способ доказательства такой — от противного.
ZEN>>>Чем "современный интернет" отличается от "современного", выделенкой что-ли? AVK>>Скоростью. ZEN>Да знаю я, чем всё это отличается.
А зачем тогда спрашиваешь?
ZEN>>>У меня модемная линия порой быстрее и стабильнее выделенки... Повезло во второй раз... AVK>>А у меня мобилка на пальма качает 4К в секунду. А на работе 256К. А у бужуев диалап составляет очень маленький процент. Что из этого следует? ZEN>Пользуйтесь выделенкой где только можно, даже в метро.
Я уже тебе сказал — лично мне мобилка позволяет выкачать фреймворк за разумное время даже в метро.
ZEN>>>Читали притчу о Вавилонской башне? Почему её не могли построить, знаете? ZEN>>>В одной голове несколько языков -- обалдеть можно! Либо один, но отлично, либо много, но удовлетворительно. Есть что изучать до старости... AVK>>Вавилонскую башню недостроили потому что люди перестали понимать чужие языки. А в дотнете языки вполне друг друга понимают. ZEN>Чужие языки? Свои, новообретённые!!!
Хорошо, пусть свои. Но фишка то не в языках, а во взаимном непонимании. Чем дотнет не страдает.
Здравствуйте AndrewVK, Вы писали:
AVK>Здравствуйте Аноним, Вы писали:
А>>Кто вам такое сказал? AVK>На java.sun.com отдельно она не лежит, поскольку javax.mail входит в состав J2EE и выкачивается AVK>вместе с ним.
Бред. JavaMailTM API Implementation
А>>+.Net AVK>Это технология а не продукт. Так что совсем не к месту.
Джаву тоже в определенном смысле можно считать не продуктом, а технологией(платформой).
А>>+...+MSIE AVK>Не нужен
Странно, а разве .Net Redist при установке не требует IE6 ?
AVK>Апач тоже в линуха интегрирован.
Тоже весьма сомнительное утверждение. Ставил я летом на древний 486-ой линукс кажется с 15 дискеток.
Apache'а там точно не было
AVK>Я вот никак не пойму — при чем здесь дотнет то? Исходники CLI лежат, бери не хочу.
Здравствуйте AndrewVK, Вы писали:
AVK>Здравствуйте Аноним, Вы писали:
<...> ZEN>>>>Есть отдельная библиотека JavaMail, которую используют разработчики и включают необходимые классы в клиентское приложение, работающее в JRE.
AVK>>>Которая входит в J2EE. И скачать ее отдельно низзя.
А>>Кто вам такое сказал? :) AVK>На java.sun.com отдельно она не лежит, поскольку javax.mail входит в состав J2EE и выкачивается AVK>вместе с ним.
Вот доступная для загрузки отдельно библиотека из J2EE (JavaMail 1.3 API): http://java.sun.com/products/javamail/index.html
AVK>>>Очень спорное утверждение. Изначально это как раз клиентская технология, просто ввиду недостаточной распространенности стандарта приходится делать преобразование на сервере.
AVK>>>Во как. А сервера что? Уже не люди? И ты знаешь сколько джавы на клиенте? В настоящее время это очень серверная платформа. И вот тут непонятно — платформа, 90% применений которой сервера распространяется без серверных библиотек. А>>J2EE -- серверные библиотеки там. AVK>Ну так я и посчитал J2SE+J2EE.
Для сервера -- правильно, но для клиента такого добра не надо.
ZEN>>>>Кхех...вы бы ещё про MSDN для .Net вспомнили, без него как без рук. AVK>>>Ок. Тогда ты к джаве еще документацию приплюсуй. В SDK документации нет. Ее отдельно качать надо.
А>>SDK -- это средство разработки, документация нужна программисту. AVK>Но не в таких(MSDN) количествах! Или в таких? ;) AVK>Ты сам предложил MSDN приплюсовать. Я что то не пойму тебя никак — AVK>для дотнета документация нужна для работы, а для джава только программисту, ты это имеешь ввиду?
Нет, не это. "Размерчики" разняться на порядок и даже два!
А>>Не путайте сервер приложений, сервер web-контента и среду исполнения. AVK>Я не путаю — это ты чего то путаешь постоянно.
Я знаю, интеграция стирает границы, трудно отделить мух от котлет.
А>>Хотя у вас другого мнения быть не может и выхода нет -- интеграция всего и вся AVK>(Windows AVK>джава уже без ОС научилась работать?
Да, уже есть Java-реализация ОС. Я имею ввиду не JavaOS, которую забросили в 1998г., а именно полноценную J2ME-систему для КПК. Ядро, естественно, на ассемблере.
А>>IIS AVK>Это компонент Windows
Ок, тогда Tomkat, пожалуйста, не относите к компонентам J2SE/J2EE -- здесь, в отличие от Windows, мы будем отделять мух от котлет.
А>>+COM AVK>Это компонент Windows, причем неотемлемый. Впрочем для веб-сервера COM не нужен.
Я говорил про COM+. Для Web-сервера он не нужен, ну раз он "неотъемлемый", то куда ж без него? :)))
А>>++ASP.Net AVK>Входит в состав .Net Redist. В отличие от.
А>>+.Net AVK>Это технология а не продукт. Так что совсем не к месту.
А>>+...+MSIE AVK>Не нужен
Как деинсталлить, чтобы не "мешался" под ногами на СЕРВЕРЕ?
А>>+MSOffice AVK>Не нужен
Что вы. Тсс...с. С ним идут важные обновления операционной системы :x
А>>+...+интегрированный_поиск_в_интернете_который_вешает_систему AVK>По желанию
Нельзя отказаться -- "неотъемлемая часть платформы". :(
ZEN>>>>А сколько всего нужно для .Net-сервера? AVK>>>.Net Redist достаточно. А SQL и Web сервер для обоих нужен.
А>>Ещё бы: IIS интегрирован в систему (Win2K, WinXP), везде есть. Неочем голове болеть. Главное -- вовремя качать патчи. :) AVK>Апач тоже в линуха интегрирован. Главное вовремя качать свежие версии. AVK>Я чего то не пойму — ты чего доказать пытаешся? Тебе шашечки или ехать?
Моторчик свой нужен :)))
ZEN>>>>Вы заплатки для IIS/MSIE и их версии считали? AVK>>>MSIE это сугубо серверный софт :). И при чем здесь заплатки? Их что — для томкета с апачей меньше надо?
Меньше. Можно посмотреть другие продукты. Sun iPlanet, например. Borland BES.
А>>Да уж, всё смешалось в этом мире...и MSIE на сервере есть, как ни странно, и работает ведь иногда. :)) AVK>Объясни внятно — зачем на сервере ставить заплатки для MSIE?
Куда без них? MSIE интегрирован в СИСТЕМУ, система безопасности зависит и от него.
А>>Как известно, качество заплаток в их своевременном обнаружении и установке. :) А>>Но главное совсем не в них, а в открытости и доступности продуктов, где можно отследить ошибки всем миром. :user: AVK>Я вот никак не пойму — при чем здесь дотнет то? Исходники CLI лежат, бери не хочу.
Не при чём. Так, к слову пришлось. Качество продуктов одной конторы обычно распространяется на все её продукты. :)
Здравствуйте IT, Вы писали:
IT>Здравствуйте iZEN, Вы писали:
IT>Дык, я тут Линукс какой-то видел на 3-х копмактах, что ж теперь считать, что по сравнению с Windows там просто два диска глюков? :???:
А я видел на 5. Кто больше?
IT>А это тут причём?
Это наверное такой способ спора — доказывать не то о чем собственно разговор.
ZEN>>Чем "современный интернет" отличается от "современного", выделенкой что-ли? У меня модемная линия порой быстрее и стабильнее выделенки...:) Повезло во второй раз...
IT>У меня вообще нет модемных линий, ни дома ни на работе, надеюсь, что скоро и у вас их не будет. Именно поэтому, разница в объёме занимаемого дистрибутива между Java и .NET не имеет абсолютно никакого значения и не может служить аргументом. Вот функциональность — да.
У меня вот увы дома модем. Но я особо не страдаю. Особенно если учесть что следующие версии виндов будут со встроенным дотнетом. А это значит что в России через пару лет процентов 70 компов будут уже с дотнетом.
IT>Да уж, приходиться пользовать каждый день как минимум — C++, C#, VB, JScript, T-SQL, XML, HTML, русский, английский :) Не представляю как всё это можно заменить одной Java :))
Вот смотри — положим я хочу тебя пригласить попить пивка в баре.
class Human {
public invite(Human whom, Action whatToDo)
public void drink(Drinks what)
private Urine piss()
private boolean isBladderFull();
public getCacheSize();
public reduceCache(float howMany);
public String prefferedBeer();
}
class DrinkBeerAction extends Action {
public Action(object[] men) {
Bar bar = new Bar();
Human iAm = people[0];
Human iT = people[1];
bar.enter(iAm);
bar.enter(iT);
while((iAm.getCacheSize() > 0)||(iT.getCacheSize() > 0)) {
while((!iAm.isBladderFull())||(!iT.isBladderFull())) {
Beer beer1 = bar.Buy("beer "+iAm.prefferedBeer());
iAm.reduceCache(beer1.getPrice());
iAm.drink(beer1);
Beer beer2 = bar.Buy("beer "+iT.prefferedBeer());
iT.reduceCache(beer2.getPrice());
iT.drink(beer2);
}
iAm.piss();
iT.piss();
}
bar.leave(iAm);
bar.leave(iT);
}
}
class Bar {
public enter(Human who);
public buy(String what);
public leave(Human who);
}
class Beer extends Drinks {
public getPrice();
}
class Main {
public static void main(String args[]) {
Human iAm = new Human();
Human iT = new Human();
iAm.invite(iT,new DrinkBeerAction(new object[]{iAm,iT}));
}
}
Здравствуйте Lloyd, Вы писали:
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.
Чувствуешь — без J2EE один фиг работать не будет — как минимум javax.activation нужен будет. Я в свое время пытался — один фиг проще J2EE скачать.
L>Странно, а разве .Net Redist при установке не требует IE6 ?
На W2K SP2 с родным IE 5.5 вполне поставился.
AVK>>Апач тоже в линуха интегрирован.
L>Тоже весьма сомнительное утверждение. Ставил я летом на древний 486-ой линукс кажется с 15 дискеток. L>Apache'а там точно не было
А я лет 10 назад с 10 дискеток Win3.1 ставил. IIS там тоже что то не припомню.
L>Это скорее исключение из правил.
Мы о дотнете говорим? Я о нем.
Здравствуйте AndrewVK, Вы писали:
IT>>Да уж, приходиться пользовать каждый день как минимум — C++, C#, VB, JScript, T-SQL, XML, HTML, русский, английский Не представляю как всё это можно заменить одной Java
AVK>Вот смотри — положим я хочу тебя пригласить попить пивка в баре.
[skip]
Да уж. Оказывается на Java можно всё, C# отдыхает.
Если нам не помогут, то мы тоже никого не пощадим.
Re[5]: В чем счастье в С#
От:
Аноним
Дата:
28.06.02 19:31
Оценка:
Здравствуйте AndrewVK, Вы писали:
<...> AVK>2) Некоторые библиотеки, аналоги которых в J2EE. Например System.Web.Mail. Да и вобще аналог System.Web.* в JRE отсутствует.
AVK>Xml (в 1.4 правда наконец то включили, но xslt там нет, только dom и sax). Web Services наконец. AVK>Короче, подводя итог, .Net Redistributable достаточен для развертывания web-приложений, а вот для развертывания web-приложений на java нужно
AVK>1) J2SE SDK 1.4 — 37М AVK>2) J2EE SDK 1.3.1 — 17М
AVK>Итого 54М. Вот такие вот пирожки с котятами.
Я разговор завёл про JRE vs. .Net Redistributable
Понимаете, в чём разница? Объясняю: "Рабочая среда для КЛИЕНТА.Что выбрать."
А вы про серверную среду говорите и возможности серверного кода у клиента.
AVK>Xml (в 1.4 правда наконец то включили, но xslt там нет, только dom и sax). Web Services наконец. AVK>Короче, подводя итог, .Net Redistributable достаточен для развертывания web-приложений, а вот для развертывания web-приложений на java нужно
AVK>1) J2SE SDK 1.4 — 37М AVK>2) J2EE SDK 1.3.1 — 17М
AVK>Итого 54М. Вот такие вот пирожки с котятами.
Я разговор завёл про JRE vs. .Net Redistributable
Понимаете, в чём разница? Объясняю: "Рабочая среда для КЛИЕНТА.Что выбрать."
А вы про серверную среду говорите и возможности серверного кода у клиента.
Здравствуйте iZEN, Вы писали:
AVK>>На java.sun.com отдельно она не лежит, поскольку javax.mail входит в состав J2EE и выкачивается AVK>>вместе с ним.
ZEN>Простейший пример почтового клиента для "чистой" J2SE: http://www.javable.com/docs/jav_mail/
И что это доказывает?
ZEN>Вот доступная для загрузки отдельно библиотека из J2EE (JavaMail 1.3 API): ZEN>http://java.sun.com/products/javamail/index.html
Как optional part of J2EE
AVK>>Ну так я и посчитал J2SE+J2EE. ZEN>Для сервера -- правильно, но для клиента такого добра не надо.
А для сервера нужно.
А>>>SDK -- это средство разработки, документация нужна программисту. AVK>>Но не в таких(MSDN) количествах! Или в таких? AVK>>Ты сам предложил MSDN приплюсовать. Я что то не пойму тебя никак — AVK>>для дотнета документация нужна для работы, а для джава только программисту, ты это имеешь ввиду? ZEN>Нет, не это. "Размерчики" разняться на порядок и даже два!
Ну так MSDN то много чего в себе содержит. Если собрать все дополнительные к джаве доки тоже размерчик огого будет.
А собственно дотнет MSDN 66М — сложи размеры доки для J2SE и J2EE. Да еще все в одном месте — не надо выкачивать кучу док, часть из которых только в html, а часть только в pdf. Как во всем этом хозяйстве что то найти?
А>>>Не путайте сервер приложений, сервер web-контента и среду исполнения. AVK>>Я не путаю — это ты чего то путаешь постоянно. ZEN>Я знаю, интеграция стирает границы, трудно отделить мух от котлет.
Давай вернемся к началу. Ты прицепился к размеру .net redist. На что я тебе возразил что .net redist это несколько больше нежели jre. При чем здесь клиенты и серверы? При чем здесь интеграция?
ZEN>Да, уже есть Java-реализация ОС. Я имею ввиду не JavaOS, которую забросили в 1998г., а именно полноценную J2ME-систему для КПК. Ядро, естественно, на ассемблере.
Вот именно что забросили. Я в курсе — можешь не рассказывать. Текущая джава без ОС не обходится.
А>>>IIS AVK>>Это компонент Windows ZEN>Ок, тогда Tomkat, пожалуйста, не относите к компонентам J2SE/J2EE -- здесь, в отличие от Windows, мы будем отделять мух от котлет.
Вот только без него JSP не запустишь.
А>>>+COM AVK>>Это компонент Windows, причем неотемлемый. Впрочем для веб-сервера COM не нужен.
ZEN>Я говорил про COM+. Для Web-сервера он не нужен, ну раз он "неотъемлемый", то куда ж без него?
COM+ отъемлемый
А>>>+...+MSIE AVK>>Не нужен ZEN>Как деинсталлить, чтобы не "мешался" под ногами на СЕРВЕРЕ?
Зачем? Мне он не мешает. Даже помогает — доки смотрю когда настраиваю.
А>>>+MSOffice AVK>>Не нужен
ZEN>Что вы. Тсс...с. С ним идут важные обновления операционной системы :x
Знаешь — у меня из офиса на домашней машине только Visio, и то с недавних времен. Удивлен?
А>>>+...+интегрированный_поиск_в_интернете_который_вешает_систему AVK>>По желанию ZEN>Ага, попались!!!
Куда? Я же не говорю что джава без EJB сервера не джава.
А>>>+Оутглюк_который полон дыр), AVK>>Не нужен ZEN>Нельзя отказаться -- "неотъемлемая часть платформы".
Можно. Это не эксплорер, не путай. Прибиваешь msimn.exe и наслаждаешся. Это я про Outlook Express. Outlook вобще отдельно ставить нужно.
ZEN>>>>>Вы заплатки для IIS/MSIE и их версии считали? AVK>>>>MSIE это сугубо серверный софт . И при чем здесь заплатки? Их что — для томкета с апачей меньше надо? ZEN>Меньше.
Да ну — ты посмотри с какой периодичностью новые версии апачи выходят. Да и томкет почитай каждый месяц выкладывают новый, да не по разу бывает.
ZEN>Можно посмотреть другие продукты. Sun iPlanet, например. Borland BES.
Меньше используют — меньше ошибок находят.
А>>>Да уж, всё смешалось в этом мире...и MSIE на сервере есть, как ни странно, и работает ведь иногда. AVK>>Объясни внятно — зачем на сервере ставить заплатки для MSIE? ZEN>Куда без них? MSIE интегрирован в СИСТЕМУ, система безопасности зависит и от него.
Проблемы с безопасностью ie будут только если ты будешь этим эксплорером смотреть наружние странички. Смотреть на работающем сервере инет — странновато, тебе так не кажется?
ZEN>Не при чём. Так, к слову пришлось. Качество продуктов одной конторы обычно распространяется на все её продукты.
Я уже тебе говорил — там не одна команда разработчиков. Есть очень хорошие продукты, есть отвратительные, есть что то среднее.
Здравствуйте Аноним, Вы писали:
А>Здравствуйте AndrewVK, Вы писали:
AVK>>1) J2SE SDK 1.4 — 37М AVK>>2) J2EE SDK 1.3.1 — 17М
AVK>>Итого 54М. Вот такие вот пирожки с котятами.
А>Я разговор завёл про JRE vs. .Net Redistributable
А я тебе ответил что .Net Redistributable = J2SE SDK + J2EE. Вот их размеры и надо сравнивать.
А>Понимаете, в чём разница? Объясняю: "Рабочая среда для КЛИЕНТА.Что выбрать." А>А вы про серверную среду говорите и возможности серверного кода у клиента.
90% применений java это серверный код. Так что актуальнее?
Здравствуйте AndrewVK, Вы писали:
AVK>Здравствуйте iZEN, Вы писали:
AVK>>>На java.sun.com отдельно она не лежит, поскольку javax.mail входит в состав J2EE и выкачивается AVK>>>вместе с ним.
ZEN>>Простейший пример почтового клиента для "чистой" J2SE: http://www.javable.com/docs/jav_mail/ AVK>И что это доказывает?
Возможностей J2SE для почтового клиента вполне хватает.
ZEN>>Вот доступная для загрузки отдельно библиотека из J2EE (JavaMail 1.3 API): ZEN>>http://java.sun.com/products/javamail/index.html
AVK>Как optional part of J2EE
Да, это для "продвинутого" почтового клиента. "Редкая птица долетит до середины Днепра." В какой мере необходима "продвинутая" птица-клиент?
AVK>>>Ну так я и посчитал J2SE+J2EE. ZEN>>Для сервера -- правильно, но для клиента такого добра не надо. AVK>А для сервера нужно.
Договорились.
А>>>>SDK -- это средство разработки, документация нужна программисту. AVK>>>Но не в таких(MSDN) количествах! Или в таких? ;) AVK>>>Ты сам предложил MSDN приплюсовать. Я что то не пойму тебя никак — AVK>>>для дотнета документация нужна для работы, а для джава только программисту, ты это имеешь ввиду? ZEN>>Нет, не это. "Размерчики" разняться на порядок и даже два! AVK>Ну так MSDN то много чего в себе содержит. Если собрать все дополнительные к джаве доки тоже размерчик огого будет. AVK>А собственно дотнет MSDN 66М — сложи размеры доки для J2SE и J2EE. Да еще все в одном месте — не надо выкачивать кучу док, часть из которых только в html, а часть только в pdf. Как во всем этом хозяйстве что то найти?
J2EE -- это компонентная надстройка над J2SE. Какой компонент используешь -- по тому компоненту и "тянешь" документацию. Компоненты, в большинстве случаев, независимы друг от друга. Это ведёт к узкой специализации разработчиков и меньшим накладным расходам в "разгребании" вагонов документации.
А>>>>Не путайте сервер приложений, сервер web-контента и среду исполнения. AVK>>>Я не путаю — это ты чего то путаешь постоянно. ZEN>>Я знаю, интеграция стирает границы, трудно отделить мух от котлет. AVK>Давай вернемся к началу. Ты прицепился к размеру .net redist. На что я тебе возразил что .net redist это несколько больше нежели jre. При чем здесь клиенты и серверы? При чем здесь интеграция?
А что нужно ставить "голому" клиенту с одной Win98?
ZEN>>Да, уже есть Java-реализация ОС. Я имею ввиду не JavaOS, которую забросили в 1998г., а именно полноценную J2ME-систему для КПК. Ядро, естественно, на ассемблере. AVK>Вот именно что забросили. Я в курсе — можешь не рассказывать. Текущая джава без ОС не обходится.
Пока да. Идеология Java несовместима с привязанностью к аппаратуре, поэтому любой "HAL"(по аналогии со Слоем Аппаратных Абстракций из WinNT) считается операционной системой для неё. :)
А>>>>IIS AVK>>>Это компонент Windows ZEN>>Ок, тогда Tomkat, пожалуйста, не относите к компонентам J2SE/J2EE -- здесь, в отличие от Windows, мы будем отделять мух от котлет. AVK>Вот только без него JSP не запустишь.
Tomcat написан на Java и работает в JRE. Можно переписать самому или написать свой. :)
А>>>>+COM AVK>>>Это компонент Windows, причем неотемлемый. Впрочем для веб-сервера COM не нужен.
ZEN>>Я говорил про COM+. Для Web-сервера он не нужен, ну раз он "неотъемлемый", то куда ж без него? :))) AVK>COM+ отъемлемый
Обычный COM тоже, кстати, "неотъемлем".
А>>>>+...+MSIE AVK>>>Не нужен ZEN>>Как деинсталлить, чтобы не "мешался" под ногами на СЕРВЕРЕ? AVK>Зачем? Мне он не мешает. Даже помогает — доки смотрю когда настраиваю.
Вы сами себе противоречите: то он вам не нужен, то нужен для "просмотра доки".
Определитесь, наконец, с сервером.
А>>>>+MSOffice AVK>>>Не нужен
ZEN>>Что вы. Тсс...с. С ним идут важные обновления операционной системы :x AVK>Знаешь — у меня из офиса на домашней машине только Visio, и то с недавних времен. Удивлен?
Ошарашен!!! Как же вы в Notepad-е тексты набираете? Правда, есть Wordpad...
А>>>>+...+интегрированный_поиск_в_интернете_который_вешает_систему AVK>>>По желанию ZEN>>Ага, попались!!! :) AVK>Куда?
На удочку льстецов из MS...:)
AVK>Я же не говорю что джава без EJB сервера не джава.
Правильно делаете -- сморозили бы глупость, вместе бы потом смеялись. :)))
А>>>>+Оутглюк_который полон дыр), AVK>>>Не нужен ZEN>>Нельзя отказаться -- "неотъемлемая часть платформы". :( AVK>Можно. Это не эксплорер, не путай. Прибиваешь msimn.exe и наслаждаешся. Это я про Outlook Express. Outlook вобще отдельно ставить нужно.
Я говорил про Outlook Express. Outlook просто нафиг никому не нужен. Насчёт "прибития" msimn.exe -- это полумера, которая лишает вас загрузчика Оутглюка, но не его функциональных COM/OLE-компонентов.
ZEN>>>>>>Вы заплатки для IIS/MSIE и их версии считали? AVK>>>>>MSIE это сугубо серверный софт :). И при чем здесь заплатки? Их что — для томкета с апачей меньше надо? ZEN>>Меньше. AVK>Да ну — ты посмотри с какой периодичностью новые версии апачи выходят. Да и томкет почитай каждый месяц выкладывают новый, да не по разу бывает.
OpenSource в развитии...Зато исходники можно глянуть и проверить, где собачка будет рыться в следующий раз.
ZEN>>Можно посмотреть другие продукты. Sun iPlanet, например. Borland BES. AVK>Меньше используют — меньше ошибок находят.
Да уж. UNIX меньше используют -- меньше ошибок находят.:)) Насмешили.
А>>>>Да уж, всё смешалось в этом мире...и MSIE на сервере есть, как ни странно, и работает ведь иногда. :)) AVK>>>Объясни внятно — зачем на сервере ставить заплатки для MSIE? ZEN>>Куда без них? MSIE интегрирован в СИСТЕМУ, система безопасности зависит и от него. AVK>Проблемы с безопасностью ie будут только если ты будешь этим эксплорером смотреть наружние странички. Смотреть на работающем сервере инет — странновато, тебе так не кажется?
Компоненты IE могут влиять на безопасность системы, будучи активизированными против желания пользователя. Разве не так?
ZEN>>Не при чём. Так, к слову пришлось. Качество продуктов одной конторы обычно распространяется на все её продукты. :) AVK>Я уже тебе говорил — там не одна команда разработчиков. Есть очень хорошие продукты, есть отвратительные, есть что то среднее.
Здравствуйте AndrewVK, Вы писали:
AVK>Здравствуйте Аноним, Вы писали:
А>>Здравствуйте AndrewVK, Вы писали:
AVK>>>1) J2SE SDK 1.4 — 37М AVK>>>2) J2EE SDK 1.3.1 — 17М
AVK>>>Итого 54М. Вот такие вот пирожки с котятами.
А>>Я разговор завёл про JRE vs. .Net Redistributable AVK>А я тебе ответил что .Net Redistributable = J2SE SDK + J2EE. Вот их размеры и надо сравнивать.
А>>Понимаете, в чём разница? Объясняю: "Рабочая среда для КЛИЕНТА.Что выбрать." А>>А вы про серверную среду говорите и возможности серверного кода у клиента. AVK>90% применений java это серверный код. Так что актуальнее?
В данном контексте полемики -- разговор идёт о размере и функциональности кода на КЛИЕНТЕ, о необходимости дополнительных прибамбасов на КЛИЕНТЕ, возможно ли избежать загрузки ненужных компонентов на КЛИЕНТА!
Прикольно. Меня всегда умиляют заявления, которые начинаются с "smth is фуфло...". Что интересно, за всё время дискуссии ни Андрей ни я не сказали, что Java фуфло. Ну, Java, ну и что. Но похоже надо действовать не так, а так:
Java есть фуфло, потому что я на ней не пишу, и даже её не пробовал, потому что это настоящий тормоз и работает по скорости примерно как скриптовые языки и может применяться только на майнфреймах из-за своей тормознутости. Вот это похоже на настоящую аргументацию
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте IT, Вы писали:
IT>Здравствуйте iZEN, Вы писали:
ZEN>>Win98 -- "средний продукт"; ZEN>>WinME -- "отвратительный продукт"; ZEN>>WinNT -- "хороший продукт"; ZEN>>Win2000 -- "лучший продукт";
ZEN>>WinXP -- "средний продукт"; ZEN>>.... -- "отвратительный продукт"; ZEN>>.... -- "хороший продукт"; ZEN>>.... -- "лучший продукт";
ZEN>>Куда идут?
IT>Прикольно. Меня всегда умиляют заявления, которые начинаются с "smth is фуфло...". Что интересно, за всё время дискуссии ни Андрей ни я не сказали, что Java фуфло. Ну, Java, ну и что. Но похоже надо действовать не так, а так:
IT>Java есть фуфло, потому что я на ней не пишу, и даже её не пробовал, потому что это настоящий тормоз и работает по скорости примерно как скриптовые языки и может применяться только на майнфреймах из-за своей тормознутости. :super: Вот это похоже на настоящую аргументацию :))
:))
Посмеялись и давайте на этом закончим. Могут не понять и те и другие "поклонники" ту чушь, что здесь прозвучала. ;)
Здравствуйте AndrewVK, Вы писали:
AVK>Здравствуйте Lloyd, Вы писали:
L>>Бред. AVK>Оттуда AVK>The JavaMailTM API is implemented as a Java platform optional package and is also available as part of the Java 2 platform, Enterprise Edition.
AVK>Чувствуешь — без J2EE один фиг работать не будет — как минимум javax.activation нужен будет. Я в свое время пытался — один фиг проще J2EE скачать.
Обрати внимание на следующий факт: в приведенной тобой цитате пишется, что это опциональный пакет, который ТАКЖЕ доступен, как часть J2EE. Что стоит на первом месте? Правильный ответ -- опциональный пакет. А то что это так же часть J2EE -- это уже вторично, как впрочем и то, что вам было проще скачать весь J2EE.
L>>Странно, а разве .Net Redist при установке не требует IE6 ? AVK>На W2K SP2 с родным IE 5.5 вполне поставился.
AVK>>>Апач тоже в линуха интегрирован.
L>>Тоже весьма сомнительное утверждение. Ставил я летом на древний 486-ой линукс кажется с 15 дискеток. L>>Apache'а там точно не было AVK>А я лет 10 назад с 10 дискеток Win3.1 ставил. IIS там тоже что то не припомню.
Моя фраза касалась вашего утверждения, что apache -- часть Linux. А это, по моему мнению совсем не так, поскольку Apache совершенно сторонний по отношению к Linux продукт. И с тем же успехом можно говорить, что он интегрирован в Windows.
L>>Это скорее исключение из правил. AVK>Мы о дотнете говорим? Я о нем.
Нет, я говорил о .Net как об эволюционной ветке развития технологий, предлагаемых Microsoft.
Здравствуйте Аноним, Вы писали:
А>Я разговор завёл про JRE vs. .Net Redistributable А>Понимаете, в чём разница?
Может все же скачаешь и посмотришь?
А>Объясняю: "Рабочая среда для КЛИЕНТА.Что выбрать." А>А вы про серверную среду говорите и возможности серверного кода у клиента.
Спорить о разнице продуктов (особенно когда один из них почти не знаешь) это здорово, но вот читая все это у меня снова всплывает однин вопрос, а где живут клиенты которые пользуются программами на Яве. Насколько я понимаю Ява на клиенте используется только созданий систем автоматизации предприятий. Так вот я занаю очень много таких российских систем, но чтобы клиент работал на Яве?!
PS
Может хватит разводить флэйм и плеваться во все стороны. Нравится Ява пиши на яве... Зачем убеждать других в ее исключительности? Читая все это складывается впечатление, что самим фактом своего появления .net унизил Яву и Sun...
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте iZEN, Вы писали:
ZEN>В данном контексте полемики -- разговор идёт о размере и функциональности кода на КЛИЕНТЕ, о необходимости дополнительных прибамбасов на КЛИЕНТЕ, возможно ли избежать загрузки ненужных компонентов на КЛИЕНТА!
Здравствуйте iZEN, Вы писали:
ZEN>>>Простейший пример почтового клиента для "чистой" J2SE: http://www.javable.com/docs/jav_mail/ AVK>>И что это доказывает? ZEN>Возможностей J2SE для почтового клиента вполне хватает.
Для возможностей почтового клиента хватает и ассемблера. Одна ко ж куда удобнее воспользоваться библиотекой.
AVK>>Как optional part of J2EE ZEN>Да, это для "продвинутого" почтового клиента. "Редкая птица долетит до середины Днепра." В какой мере необходима "продвинутая" птица-клиент?
Как только тебе понадобятся аттачи. И не только на клиенте. Сервер тоже принимать и отсылать может.
AVK>>Ну так MSDN то много чего в себе содержит. Если собрать все дополнительные к джаве доки тоже размерчик огого будет. AVK>>А собственно дотнет MSDN 66М — сложи размеры доки для J2SE и J2EE. Да еще все в одном месте — не надо выкачивать кучу док, часть из которых только в html, а часть только в pdf. Как во всем этом хозяйстве что то найти? ZEN>J2EE -- это компонентная надстройка над J2SE. Какой компонент используешь -- по тому компоненту и "тянешь" документацию. Компоненты, в большинстве случаев, независимы друг от друга. Это ведёт к узкой специализации разработчиков и меньшим накладным расходам в "разгребании" вагонов документации.
Практика показывает что пользоваться документацией дотнета намного удобнее чем документацией к джаве.
AVK>>Давай вернемся к началу. Ты прицепился к размеру .net redist. На что я тебе возразил что .net redist это несколько больше нежели jre. При чем здесь клиенты и серверы? При чем здесь интеграция? ZEN>А что нужно ставить "голому" клиенту с одной Win98?
А что нужно ставить голому веб серверу? Т.е. резюмируя — на джава клиента надо ставить меньше по объему, на джава сервер больше. Причем в обоих случаях разница несущественна.
AVK>>Вот именно что забросили. Я в курсе — можешь не рассказывать. Текущая джава без ОС не обходится. ZEN>Пока да.
Совсем да
AVK>>Вот только без него JSP не запустишь. ZEN>Tomcat написан на Java и работает в JRE. Можно переписать самому или написать свой.
Ну так и для дотнета можно свой веб сервер написать. На ассемблере к примеру
ZEN>>>Я говорил про COM+. Для Web-сервера он не нужен, ну раз он "неотъемлемый", то куда ж без него? AVK>>COM+ отъемлемый ZEN>Обычный COM тоже, кстати, "неотъемлем".
На данный момент отнятие COM у WinXP приведет к полной ее неработоспособности.
А>>>>>+...+MSIE AVK>>>>Не нужен ZEN>>>Как деинсталлить, чтобы не "мешался" под ногами на СЕРВЕРЕ? AVK>>Зачем? Мне он не мешает. Даже помогает — доки смотрю когда настраиваю.
ZEN>Вы сами себе противоречите: то он вам не нужен, то нужен для "просмотра доки".
Дока ЛОКАЛЬНО лежит на диске.
ZEN>Ошарашен!!! Как же вы в Notepad-е тексты набираете? Правда, есть Wordpad...
Я тексты не часто набираю. Стараюсь обходиться. Принтер вон с полки уже год наверное не снимал.
ZEN>Правильно делаете -- сморозили бы глупость, вместе бы потом смеялись.
Ну так indexing сервер имеет даже меньшее отношение к дотнету нежели EJB-сервер к джаве.
ZEN>Я говорил про Outlook Express. Outlook просто нафиг никому не нужен. Насчёт "прибития" msimn.exe -- это полумера, которая лишает вас загрузчика Оутглюка, но не его функциональных COM/OLE-компонентов.
Не путай с эксплорером. OE со всеми своими наворотами лежит в папке Program Files/Outlook express. Весь функциональный код в msoe.dll (1.2М). Удаляешь эту папку и никакими извращениями тебе OE запустить не удастся.
AVK>>Да ну — ты посмотри с какой периодичностью новые версии апачи выходят. Да и томкет почитай каждый месяц выкладывают новый, да не по разу бывает. ZEN>OpenSource в развитии...Зато исходники можно глянуть и проверить, где собачка будет рыться в следующий раз.
Ну так выкачивать то постоянно надо.
ZEN>>>Можно посмотреть другие продукты. Sun iPlanet, например. Borland BES. AVK>>Меньше используют — меньше ошибок находят. ZEN>Да уж. UNIX меньше используют -- меньше ошибок находят. Насмешили.
А ты думаешь в юнихах ошибок нет?
AVK>>Проблемы с безопасностью ie будут только если ты будешь этим эксплорером смотреть наружние странички. Смотреть на работающем сервере инет — странновато, тебе так не кажется? ZEN>Компоненты IE могут влиять на безопасность системы, будучи активизированными против желания пользователя. Разве не так?
Не так.
ZEN>>>Не при чём. Так, к слову пришлось. Качество продуктов одной конторы обычно распространяется на все её продукты. AVK>>Я уже тебе говорил — там не одна команда разработчиков. Есть очень хорошие продукты, есть отвратительные, есть что то среднее.
ZEN>Win98 -- "средний продукт"; ZEN>WinME -- "отвратительный продукт"; ZEN>WinNT -- "хороший продукт"; ZEN>Win2000 -- "лучший продукт";
ZEN>WinXP -- "средний продукт"; ZEN>.... -- "отвратительный продукт"; ZEN>.... -- "хороший продукт"; ZEN>.... -- "лучший продукт";
ZEN>Куда идут?
Лично мне кажется что по качеству WinXP = Win2000 и лучше NT4, намного лучше NT 3.51. Куда идут?
Здравствуйте iZEN, Вы писали:
А>>>Понимаете, в чём разница? Объясняю: "Рабочая среда для КЛИЕНТА.Что выбрать." А>>>А вы про серверную среду говорите и возможности серверного кода у клиента. AVK>>90% применений java это серверный код. Так что актуальнее? ZEN>В данном контексте полемики -- разговор идёт о размере и функциональности кода на КЛИЕНТЕ, о необходимости дополнительных прибамбасов на КЛИЕНТЕ, возможно ли избежать загрузки ненужных компонентов на КЛИЕНТА!
Это ты уже сам разговор перевел. В начале слово клиент даже не упоминалось.
Здравствуйте Lloyd, Вы писали:
L>Обрати внимание на следующий факт: в приведенной тобой цитате пишется, что это опциональный пакет, который ТАКЖЕ доступен, как часть J2EE. Что стоит на первом месте? Правильный ответ -- опциональный пакет. А то что это так же часть J2EE -- это уже вторично, как впрочем и то, что вам было проще скачать весь J2EE.
Перевожу — для работы опционального Java Mail нужен J2EE
L>>>Тоже весьма сомнительное утверждение. Ставил я летом на древний 486-ой линукс кажется с 15 дискеток. L>>>Apache'а там точно не было AVK>>А я лет 10 назад с 10 дискеток Win3.1 ставил. IIS там тоже что то не припомню. L>Моя фраза касалась вашего утверждения, что apache -- часть Linux. А это, по моему мнению совсем не так, поскольку Apache совершенно сторонний по отношению к Linux продукт. И с тем же успехом можно говорить, что он интегрирован в Windows.
Во всех современных дистрибутивах линукса есть апач. Также как во всех современных дистрибутивах виндов есть IIS. Вот и все что я хотел сказать.
L>Нет, я говорил о .Net как об эволюционной ветке развития технологий, предлагаемых Microsoft.
Эволюционной? Я бы назвал дотнет революционным для MS. Эволюционным было OLE — OLE 2 — COM — COM+.
Здравствуйте AndrewVK, Вы писали:
AVK>Здравствуйте Lloyd, Вы писали:
L>>Обрати внимание на следующий факт: в приведенной тобой цитате пишется, что это опциональный пакет, который ТАКЖЕ доступен, как часть J2EE. Что стоит на первом месте? Правильный ответ -- опциональный пакет. А то что это так же часть J2EE -- это уже вторично, как впрочем и то, что вам было проще скачать весь J2EE. AVK>Перевожу — для работы опционального Java Mail нужен J2EE
Как-то вы неправильно перевели.
Разве не так правильнее?
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.
L>>>>Тоже весьма сомнительное утверждение. Ставил я летом на древний 486-ой линукс кажется с 15 дискеток. L>>>>Apache'а там точно не было AVK>>>А я лет 10 назад с 10 дискеток Win3.1 ставил. IIS там тоже что то не припомню. L>>Моя фраза касалась вашего утверждения, что apache -- часть Linux. А это, по моему мнению совсем не так, поскольку Apache совершенно сторонний по отношению к Linux продукт. И с тем же успехом можно говорить, что он интегрирован в Windows. AVK>Во всех современных дистрибутивах линукса есть апач. Также как во всех современных дистрибутивах виндов есть IIS. Вот и все что я хотел сказать.
Дык там мнеого чего есть из этого вовсе не следует, что все, что там есть -- интергрированно.
L>>Нет, я говорил о .Net как об эволюционной ветке развития технологий, предлагаемых Microsoft. AVK>Эволюционной? Я бы назвал дотнет революционным для MS. Эволюционным было OLE — OLE 2 — COM — COM+.
Эволюционный или революционный, это не столь важно. Я хотел лишь сказать, что раскрываение Mictosoft'ом своих исходных кодов скорее сключение, чем правило.
Здравствуйте 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'ом не правильно себя вел. А мог бы на этом круто навариться.
Здравствуйте 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
А-га! А в этом русском еще правла понасованы, да еще и компилятора нормального не прилогается. Один Ворд и тот тормозной интерпретатор.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте 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 моложе 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 — спасение от всех зол.
Если нам не помогут, то мы тоже никого не пощадим.
ZEN>Я считаю: меньше размер -- меньше потенциальных ошибок в коде. ZEN>Слышали, наверное, о "рекорде" "ServicePack для WindowsXP будет весить 600Мб" -- насколько это сопоставимо с размером самой системы?
Это вам кто-то из посвящённых на совместной пьянке рассказал? У меня лично SP1 beta1 для XP 117 Мб занимает...
0 программистов ругал сердитый шеф,
потом уволил одного, и стало их FF!
Здравствуйте IT, Вы писали:
IT>Но, но, но! Я папрашу! IT>Я заменял, заменяю и буду заменять все комы, которые только можно, на web-сервисы. У меня проблем с их скоростями нету, надо будет ещё пару процессоров в сервер воткнём. А вот deployment меня волнует серьёзно. После каждого изменения COM-объекта перегружать сотни рабочих станций мне никто не позволит. С remoting на клиентах тоже пока сильно не разбежишься, так что получается, что пока WS — спасение от всех зол.
А вот можно поподробнее — пачему ремотинг хуже веб-сервисов? У вас клиенты не дотнетовские?
Здравствуйте VladD2, Вы писали:
VD>Здравствуйте AndrewVK, Вы писали:
VD>>>Если они посчитали что изменений много, то нужно было довать версию 2 (или 7 как MS), а не заниматься дурью. AVK>>Да какая нафик разница. Как не называй, суть то одна.
VD>Неразбериха. Вот суть таких именований.
Ага. MS можно, а Sun нельзя? MS Word6 помним, MS Word7 помним(?), MS Word97 помним (где "настоящая" версия 8?), и так далее...
AVK>>Революции разные бывают. Под революцией я понимаю ситуацию, когда приходится отказываться от старых наработок. А что это — какие то глобальные идеи или небольшой класс, не суть важно.
VD>В восьмедисятых для таких преобразований приспособили слово перестройка. :)
AVK>>Это революция не вобще, а по сравнению с предыдущей версией.
VD>Дык если есть версии, то однозначно эволюция. Типа лапки вместо плавников.
AVK>>Какой такой? 1.1.6 был вполне применим в коммерческих проектах. Скорость его была конечно же поменьше 1.3, но для многих задач вполне достаточна.
"Проба пера" JIT-а.
VD>Я о том, что на разницу в двое я глаза еще закрою, но в 10 раз — это уже перебор, а 1.1.х тормозили по черному. Есть задачи не критичные ко времени, но вом мне все как-то другие попадаются. :(
Тормозило без JIT-а и с самыми первыми JIT-ами.
AVK>>Рефлекшн джавы не обеспечивает достаточную для реализации визуального программирования функциональность. Там нет способа сказать что тот или иной метод на самом деле property accessor
Так ли не обеспечивает? И всё ли нужно?
Reflection может выдать только ту информацию о классе, его методах и полях, которая содержится в уже откомпилированном классе. По-моему, избыточной информации для RUN-TIME быть не должно, а для DESIGN-TIME должен предоставляться BeanInfo и, по желанию, "навороченные" PropertyEditors и только в том случае, если разработчик Bean-а захочет, чтобы Вы использовали его компонент в СРЕДЕ РАЗРАБОТКИ и/или Bean-контейнере.
Я считаю, что правильно отделили классы поддержки разработки от самого компонента -- в Run-time и в Design-time нужны разные непересекающиеся вещи.
VD>Ну, это они вроде неплохо и по именам отиличают. В конце концов можно было бы с эмулировать свойства в простых текстовых файлах (все равно их используют).
AVK>>Влад, BeanInfo можно вобще не писать для компоненты. Это опциональная вещь. Основа java beans это соглашение об именовании методов доступа к свойствам.
VD>Можно, но за тебя его создадут. Главное, что ты не можешь переплюнуть логику компонента реализованного через нестандартные реализации этой лабуды, а занчит обязан все это читать через все эит BeanInfo.
VD>>> Рефлекшон полность мог бы решить эти задачи, хотя конечно наличие тех же атрибутов сильно упростило бы задачу.
Нет, он решает определённые задачи.
Java-рефлекшн может дать то, что есть, не больше, не меньше. А обычно есть только самое необходимое для работы в Run-time. Для Design-time требуются (подчёркиваю: необязательно!!!) дополнительные классы поддержки разработки: BeanInfo -- для корректного отображения свойств компонента в ObjectInspector-ах различных IDE (например, отобразить цвет не словами, а цветной фигуркой, тип цветной фигурки может быть на совести IDE или PropertyEditor-а) и PropertyEditor-ы -- для "наикрутейшего" доступа к "свойствам" (например, задание коннекта к БД одной строчкой, но после вызова настоящего диалога с полями "имя_пользователя", "пароль", "драйвер", "url_базы", и т.д.).
AVK>>Вот и расскажи как, используя джавовский рефлекшен, это реализовать.
VD>Я с ней не возился, но по описанию они мало чем отличается от Нэтовской. Атрибуты запихиваем в файл. Не очень красиво, но лучше чем паралельное тайп-инофо воротить.
А вдруг пользователь "наткнётся" на "интересный" текстовый файл и захочет немного "поправить положение вещей", что тогда? Хотя, конечно, такая информация нужна только разработчику в Design-time, но никак не конечному пользователю. :)
AVK>>Влад, в данном случае ты просто не в курсе. BeanInfo это вспомогательные классы.
VD>Насколько я знаю, их можно реализовывать самостоятельно, а значит в объод двигаться нельзя. Т.е. даже появление атрибутов не приведет к изменению схемы. Ну, или снова будут гудеть о революции.
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.
VD>Я цитаты драть не буду, но помню, что там еще были слова типа "если вам нужно вы можете сварганить все сами...".
Можно и самим. Конечно, если нам нужно. :)
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 свойства добавить с делегатами и не выпендриваться пудря мозги про конноы ОО?
Рефлекшн порой нужен бывает для реализации простейшего механизма "PLUG-IN" в Run-time. Поэтому в Java это не относится к чуду, но, скорее, как к данности этой технологии.
VD>>> хотя CODEDOM с его недокументированностью получился тяжеловатым и молопонятным. AVK>>Вот тут как раз и помогли бы исходники.
VD>Кто бы спрорил. Но лучши исходники и документация. :)
Исходники вместе с документацией == JavaDoc. :) Классно!
AVK>>Так сразу бы и говорил что тебе не нравится механизм BeanInfo, а не java beans. Особенно непонятно при чем здесь EJB.
VD>Дык это и есть главная особенность бобов. Я честно говоря думал Ё-джибя так же сделаны.
EJB -- одна из инфраструктур(!) J2EE. Почему EJB их нельзя назвать "Beans"? EJB -- это настоящие компоненты (бизнес-компоненты), а значит, "Beans" и им подходит!
VD>>>Удобный... не удобный. Глваное необходимый. И идеологически лишний. К тому же эта дурная идеология говорит, что якобы компоненты начинаются с бобов, хотя любой скомпилированный класс в Яве является по существу компонентом.
AVK>>Влад, ты просто не в курсе.
VD>Я в курсе, что есть дефолтная реализация.
VD>>>В Нэте тоже ввели интерфейс, но он вообще ничего не делает. AVK>>Какой интерфейс?
VD>IComponent
VD>Я честно говоря считаю, что это тоже ошибка. Любой класс должен быть компонентом если это позволяет система. В Нэт и Яве это возможно, но не реализовано. :( Причем в Яве худшая форма.
Ну, если любой класс считать компонентом, тогда да.
Хотя JavaBean-ом можно назвать лишь класс с public-конструктором, у которого нет параметров (для корректного инстанцирования такого класса в Bean-контейнере).
VD>>>Эээ... батенька. Нэт обходтися без ненужных примочек. Есть пути порулить, но они опциональные. AVK>>Ну так BeanInfo и PropertyEditor тоже опциональные.
Добавлю: BeanInfo и расширенные PropertyEditor-ы нужны для "самостоятельного" руления IDE.
VD>Не, ты не можешь ралботать с бинам через рефлекшон, так как найдется один боб который не будет соотвествовать своему описанию.
Да ну? Вот насмешил. :))) Рефлекшн даёт только то, что есть в классе. Нам самим решать, какие методы соответствуют тому или иному "свойству" и что они делают.
Всё остальное -- BeanInfo и расширенные PropertyEditors -- только помогают понять нам сущность класса и то, что хотел сказать нам разработчик класса, и работать с ним в Design-time.
VD>>> По умолчанию тоже PropertyEditor пользуется решлекшоном, а значит я могу вывести в него любой объект. И файл ему отдельный с надписью "А точно является компонентом" не нужен. AVK>>В джаве все точно так же.
VD>Нет, в Яве по умолчанию создается умолчальная реализация всех этих BeanInfo и Introspector-ов, а уже она лезит к компонентам. Получается явная замена рефлекшона. Ольтернатива для получения информации о типах.
Да ничего не создаётся! Если нет BeanInfo и PropertyEditor-ов, то обходимся меньшим -- одним Рефлекшном и всё пучком.
VD>>> Еджиби же вообще один популизм. Все тоже самое можно было делать и без выделенного класса компонентов. AVK>>А его и нет, выделенного класса. Есть только интерфейсы. А базовые классы для EJB у каждого сервера свои. EJB вобще больше похожи на aspx чем на классы как таковые.
VD>Класное достижение!
EJB -- инфраструктура J2EE, фреймворк. Конкретные реализации EJB -- это уже бизнес-объекты в инфраструктуре J2EE.
VD>>>Вот это я называю неграмотным проектированием и ламерской реализацией. К тому же у них есть одна общая вещь... И те и другие компоненты. Хотя чем хуже все остальные??? AVK>>Проектирование то тут при чем? Просто не очень удачное название.
VD>Дык все эти Явы и Нэты спроектированы били...
AVK>>Где то в инете видел исследование — производительность современных компьютеров в 95% случаев избыточна.
VD>Это пускай читают, те кто програм никогда не писал. У меня на столе стоит Атлон ХаРэ 2000+ и я как то не часто замечаю что его производительность избыточна. Даже тот же ворд на серьезных документах тормозит.
VD>>>Пока есть только одно неоспоримое преимущество — легкая и быстрая реализация компонентов. Это особо актуально для бизнес-приложений, для остальных же все не так однозначно. AVK>>Так бизнес-приложения это основные деньги. Завоевать рынок платформ для коробочного софта я думаю ни Sun ни MS особо не стремятся.
VD>Ты это MS или Sun-у раскажи. :) Вот они посмеются... Деньги есть везде. Врочем как и сложные задачи. Среда которая первая займет подовлющее большинство питательных ниш и будет победителем. Это как в стратегиях.
AVK>>Ну а основное преимущество джавы и шарпа в скорости разработки.
VD>Скорость разработки на том же VB6 ни чуть не ниже. Есть и другие примеры. Все важно в комплексе.
AVK>>К примеру тот же развитый рефлекшн по сути замешает темплейты, естественно ценой быстродействия.
VD>Это разные вещи. К тому же быстродействие и типобезопастность это главные выгоды от генерик-типов.
VD>>> А если появятся грамотно реализованные шоблоны, то и этот фиговый листок отпадет за ненадобностью. AVK>>Все это очень неоднозначно. Выиграем тут проиграем там.
VD>Не вот тут вот все будет однозначно. Если конечно не будет сильных побочных эффектов, типа сильного замедления компиляции.
AVK>>>>Та же Дельфи, при отсутствии шаблонов, множественного наследования и много чего еще вполне успешно конкурирует с С++. VD>>>Не очень то успешно. Только в одной нише (догадайся в кака?). AVK>>Тем не менее коммерческий успех есть.
Только в России! :))
VD>Для борланда хватает, но Sun и MS за эти деньги даже пальцем не пошевельнули бы, так что все относитльно. Мы бы думаю были рады даже такому куску. :)
Здравствуйте VladD2, Вы писали:
VD>Ты... Это... того... приезжай к нам и привози свои линии безмодемные. А то вон народ размечтался о закачке Явы с Нэтом в метро на мобильный. А в мобильных пока, что даже памяти такой нет чтобы их разместить,
Да есть ужо, ты Влад от жизни отстал. Да и пальма у меня.
VD>Кстати если развивать перенос притчи, то MS получается вроде бога. А с ними лучше не спорить. (все же демогогия убедительная вещь) .
Нет бога окромя MS и Билл Гейтс пророк его.
VD>А-га! А в этом русском еще правла понасованы, да еще и компилятора нормального не прилогается. Один Ворд и тот тормозной интерпретатор.
Я себе компилятор русского языка представил. К примеру я говорю что стукну тебя по башке. Это все компилируется, запускается и ты ощущаешь что тебя стукнули по башке. Круть!
ZEN>>Я считаю: меньше размер -- меньше потенциальных ошибок в коде. ZEN>>Слышали, наверное, о "рекорде" "ServicePack для WindowsXP будет весить 600Мб" -- насколько это сопоставимо с размером самой системы?
Z2>Это вам кто-то из посвящённых на совместной пьянке рассказал? У меня лично SP1 beta1 для XP 117 Мб занимает...
Цитата (можно, конечно, пропустить мимо ушей:))):
"Microsoft выпустит Service Pack 1 для Windows XP досрочно
Недавно мы уже сообщали, что Microsoft предоставила тестерам первую бета-версию Service Pack 1 для Windows XP. Всезнающий сайт The Inquirer сообщил со ссылкой на информированные источники, что корпорация Microsoft решила выпустить первый Service Pack для ОС Windows XP досрочно. Это может произойдти еще до конца этого месяца.
Напомним, что выпуск самой ОС Windows XP состоялся в конце октября 2001 г. А уже в этом году Microsoft объявила, что Service Pack выйдет приблизительно в сентябре. Но, по всей видимости, много накопилось дополнений и особенно исправлений для исходной версии, что Microsoft решила поторопиться. Во всяком случае, в недавнем уведомлении о некорректной работе системного регистра, которая может привести к аварийному закрытию системы, пользователям предлагалось подождать для решения этой проблемы Service Pack 1. Это косвенно подтверждает досрочный выпуск этого продукта.
Здравствуйте iZEN, Вы писали:
ZEN>Так ли не обеспечивает?
Не обеспечивает. Для того и BeanInfo придумали.
ZEN> И всё ли нужно?
Все. На практике отделение метаданных от класса (как например в том же EJB) весьма геморойно. Все серьезные разработки на EJB которые я видел пользуют свои собственные генераторы бинов и деплоймент дескрипторов. Это показатель. Атрибуты могут эту проблему решить.
ZEN>Я считаю, что правильно отделили классы поддержки разработки от самого компонента -- в Run-time и в Design-time нужны разные непересекающиеся вещи.
И все таки атрибуты это более элегантное решение. Впрочем в 1.5 что то подобное будет.
ZEN>EJB -- одна из инфраструктур(!) J2EE. Почему EJB их нельзя назвать "Beans"? EJB -- это настоящие компоненты (бизнес-компоненты), а значит, "Beans" и им подходит!
Очень оно слово такое, компонент, многозначное.
ZEN>Ну, если любой класс считать компонентом, тогда да. ZEN>Хотя JavaBean-ом можно назвать лишь класс с public-конструктором, у которого нет параметров (для корректного инстанцирования такого класса в Bean-контейнере).
А вот тут в джаве есть прокол в плане дизайна свинга. За каким они не придерживаются этого для некоторых классов для представления свойств. Тот же Layout ,если мне не изменяет память, не имеет конструктора без параметров.
Здравствуйте AndrewVK, Вы писали:
IT>>Я заменял, заменяю и буду заменять все комы, которые только можно, на web-сервисы. У меня проблем с их скоростями нету, надо будет ещё пару процессоров в сервер воткнём. А вот deployment меня волнует серьёзно. После каждого изменения COM-объекта перегружать сотни рабочих станций мне никто не позволит. С remoting на клиентах тоже пока сильно не разбежишься, так что получается, что пока WS — спасение от всех зол.
AVK>А вот можно поподробнее — пачему ремотинг хуже веб-сервисов? У вас клиенты не дотнетовские?
Основное приложение не дот-нетовское. Это 2.75 уровневая система, написанная на MFC ещё года три-четыре назад, и она постоянно обновляется и поддерживается. Проблема в том, что вынуть шашки и с криками "За царя, за отечество!" переписать её ни за месяц, ни за два не удастся, да никто и не позволить всё сразу ломать. Здесь как раз к месту принцип "Лучшее — враг хорошего". Проблема ещё и в том, что с этой системой работают уже прошедшие обучение люди в разных штатах и странах. А это сотни рабочих станций, которые нужно проапгрейтить и поставить на них .NET.
В общем-то, работы ведутся, из всего этого барахла постепенно вынимаются кусочки и переносятся на аппликейшн сервера, местами начинаем применять браузерные технологии вместо обычного виндового UI, но до полного перехода на .NET ещё далеко.
Правда полно задач, которые не так критичны к деплойменту. Если например, программа планируется быть используемой только на двух-трех десятках машин, то вопрос об апгрейте даже не стоит.
К тому же ещё и девелоперов надо переучивать, хотя веб-сервисы народ берёт всего за пару дней, в отличии от COM, на который требуются недели, а иногда и месяцы.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте AndrewVK, Вы писали:
AVK>Здравствуйте iZEN, Вы писали:
ZEN>>Так ли не обеспечивает? AVK>Не обеспечивает. Для того и BeanInfo придумали.
В Run-time BeanInfo излишне, вот и придумали -- "отделили мух от котлет".
ZEN>> И всё ли нужно? AVK>Все. На практике отделение метаданных от класса (как например в том же EJB) весьма геморойно. Все серьезные разработки на EJB которые я видел пользуют свои собственные генераторы бинов и деплоймент дескрипторов. Это показатель. Атрибуты могут эту проблему решить.
Возможно. Не буду спорить. Но пока производители EJB-контейнеров не договорятся о единых способах работы с EJB и БД, такое -- чистая утопия.
ZEN>>Я считаю, что правильно отделили классы поддержки разработки от самого компонента -- в Run-time и в Design-time нужны разные непересекающиеся вещи. AVK>И все таки атрибуты это более элегантное решение. Впрочем в 1.5 что то подобное будет.
Посмотрим. По-моему, это всё равно, что засовывать JavaDoc в откомпилированный класс.:)
ZEN>>EJB -- одна из инфраструктур(!) J2EE. Почему EJB их нельзя назвать "Beans"? EJB -- это настоящие компоненты (бизнес-компоненты), а значит, "Beans" и им подходит! AVK>Очень оно слово такое, компонент, многозначное.
Вот и вы согласились с многозначностью названия "компонент".
ZEN>>Ну, если любой класс считать компонентом, тогда да. ZEN>>Хотя JavaBean-ом можно назвать лишь класс с public-конструктором, у которого нет параметров (для корректного инстанцирования такого класса в Bean-контейнере). AVK>А вот тут в джаве есть прокол в плане дизайна свинга. За каким они не придерживаются этого для некоторых классов для представления свойств. Тот же Layout ,если мне не изменяет память, не имеет конструктора без параметров.
Классы менеджеров компоновки (Layouts) не обязаны иметь такой конструктор, потому что они -- "несовсем" компоненты. Возможно, такое ограничение на конструктор уже снято, однако в утилиту тестирования "BeanBox" такой компонент не положишь...:)
Re[17]: В чем счастье в С#
От:
Аноним
Дата:
02.07.02 15:47
Оценка:
Здравствуйте AndrewVK, Вы писали:
ZEN>>Ну, если любой класс считать компонентом, тогда да. ZEN>>Хотя JavaBean-ом можно назвать лишь класс с public-конструктором, у которого нет параметров (для корректного инстанцирования такого класса в Bean-контейнере). AVK>А вот тут в джаве есть прокол в плане дизайна свинга. За каким они не придерживаются этого для некоторых классов для представления свойств. Тот же Layout ,если мне не изменяет память, не имеет конструктора без параметров.
Специально посмотрел.
Только javax.swing.BoxLayout не имеет конструктора без параметров.
Все остальные стандартные Layout-ы имеют конструктор без параметров.
Здравствуйте AndrewVK, Вы писали:
ZEN>>Ну, если любой класс считать компонентом, тогда да. ZEN>>Хотя JavaBean-ом можно назвать лишь класс с public-конструктором, у которого нет параметров (для корректного инстанцирования такого класса в Bean-контейнере). AVK>А вот тут в джаве есть прокол в плане дизайна свинга. За каким они не придерживаются этого для некоторых классов для представления свойств. Тот же Layout ,если мне не изменяет память, не имеет конструктора без параметров.
Специально посмотрел.
Только javax.swing.BoxLayout не имеет конструктора без параметров.
Все остальные стандартные Layout-ы имеют конструктор без параметров.
Здравствуйте iZEN, Вы писали:
AVK>>А вот тут в джаве есть прокол в плане дизайна свинга. За каким они не придерживаются этого для некоторых классов для представления свойств. Тот же Layout ,если мне не изменяет память, не имеет конструктора без параметров.
ZEN>Классы менеджеров компоновки (Layouts) не обязаны иметь такой конструктор, потому что они -- "несовсем" компоненты.
О том и речь. Для редактирования такого класса обязательно нужен его property editor чтобы знать какой параметр нужно передать конструктору. А в некоторых случаях (к примеру в случае long term persistence) это может происходить во время работы программы, а не только при дизайне.
Здравствуйте Аноним, Вы писали:
А>Специально посмотрел. А>Только javax.swing.BoxLayout не имеет конструктора без параметров. А>Все остальные стандартные Layout-ы имеют конструктор без параметров.
Ну так не имеет же. Да и не только Layout, Size тоже вроде не имеет.
Здравствуйте AndrewVK, Вы писали:
AVK>Ну в 10 раз только на очень определенных моментах. Суммарно раза в 1.5-2.
1.5-2 это показатели для Явы 1.3 (вызванные как я понимаю в основном динамическим полиморфизмом).
AVK>Time critical задачи нельзя решать ни на тогдашней джаве ни на теперешнем дотнете.
Начнем с тог что назвать "критичными ко времени". Реалтайм наверно пка рановато, но обычные приложения уже можно. Десктоп на нете работает неплохо. Вот игры, анализ сложный и т.п. пока что тяжело, но если эвулюция будет двигаться вперед, то и это станет возможным. Нэт уже можно применять в большем классе задачь. Тоте же десктоп приложения я пока не отчаюсь создавать на Яве, а на Нэте влет. Я уже даже успел создать небольшое приложенице и мы его уже используем в штатном режиме для основной работы. Кстати я по нему должен еще статейку для RSDN Mag #1 дописать. Будет типа живой пример в картинках. :) Тормоза Явы во многом таятся не в слабостях джита, а в гупосте кодировщиков и архитекторов. Их желание получить полностью переносимый код доходило ранее до маразма. MS в этом отношении более сдержан. Есть переносимый серверный слой и клиент под виндовс. Плюсы: быстрый и качественный GUI, легкость реализации библиотеки, простота расширения (например, в EditBox не оказалось команды позиционирования к выделенной области текста и я с легкостью дописал такой метод использовав сообщения виндовс), ну, и для MS... он остается лидером хотя бы на рабочих станциях.
Как по твоему не лучше бы было положение Явы если у нее вместо свинга под виндовс была библиотека типа VCL или WinForms?
AVK>И еще — я уже не раз говорил, платформы вроде джавы и дотнета проектировались с прицелом не на кодера, а на дизайнера.
Ту это уже ерунда. То, что нужно упрощать процесс программирования/проектирования, тут никто не спорит. Работать за ними все равно тем же кодерам. Ту же яву стали использовать когда программист смог получить в руки удобные инструменты типа ЯваБилдера, а ведь язык не изменился почти...
AVK>В этом их принципиальное отличие от языков предыдущего поколения.
Я в 94 используя Gupta SQL Base имел почти все то, что мне предлагают в яве. Разве что переносимости небыло...
Высокоуровневые языки были давно. Возьми тот же VB. Можно плеваться сколько угодно, но ява в разы сложнее VB5-6, а приложения можно делать и на том, и на том.
AVK> Сейчас стало возможным пожертвовать эффективностью
Пожертвовать эффективностю можно было всегда. Вот толко все же лучше этого не делать. Я уже где-то говорил, что все достойные программы пишутся на пределе возмжностей железа. Если процессор станет быстрее программы прсто станут интеллектуальнее и функциональные. И вообще хватит про жизнь за 33 мегогерцами...
VD>>Ну, это они вроде неплохо и по именам отиличают. AVK>Ну так это и есть java beans. А ты о чем подумал?
Давай канчать бестолково спорить.
В обычных бобах (ты сам об этом говорил) придуманы дополнительные средства — BeanInfo (и т.п.)
Давай так я перечислю свои утверждения и сделаю вывод, а ты уж сформулируй их критику.
1. Мое определение компонента: Объект (класс) оформленный в виде отчуждаемого модуля содержащего все необходимое описание и т.п. для использования объекта за пределами компьютра на котором был создан объект. Компонент должен иметь возможность использования как компилирующими так и интерпритирующими средсвами. Компонент не должен требовать статического подключения и дополнительного описания (например, заголовочных файлов).
2. Ява обладает механизмами для того чтобы обеспечить компонентную разработку. Средства определения свойств не всчет, так как данная парадигма отрицается создателями языка (и платформы) как ересь.
3. BeanInfo является дополнительным стандартом определения информации о типах.
4. Самостоятельная реализация BeanInfo может вернуть информацию о типах отличную от той которую можн было бы получить с помощью рефлекшона.
5. (Базируется на пункте 5.) Стандартизация BeanInfo заставляет использовать именно его для получения информации о бинах.
6. Модель Ё-бинов сделана отличным от бинов и рефлекшона компонентной модели.
7. (Основано на всех предыдущих пунктах) Компонентаная модель Явы непоследовательна, противоричива и не стройна.
8. Компонентная модель Нэта красива, стройна и почти не противоречива.
"Почти" потому, как интерфейс компонент введен зря. Любой public класс Нэта является по сути компонентом (отвечает требованиям к компоненту).
VD>> В конце концов можно было бы с эмулировать свойства в простых текстовых файлах (все равно их используют). AVK>Классы гибче.
Эта гибкость портит компонентную модель. Что, по-моему, дароже.
AVK>>>Влад, BeanInfo можно вобще не писать для компоненты. Это опциональная вещь. Основа java beans это соглашение об именовании методов доступа к свойствам. VD>>Можно, но за тебя его создадут. AVK>Кто? Я в свое время изучал код Introspector — никто там ничего не создает. Сначала пытаются залезть через рефлекшн. А потом пытаются уже найти BeanInfo. Если не находят отдают то что удалось найти. Более того, можно заставить интроспектора игнорировать BeanInfo.
Это как это "Introspector — никто там ничего не создает" Ты хоть вдумайся в свои влова "Сначала пытаются залезть через рефлекшн". Это означает, что Introspector читает рефлекшон и на лету создает реализацию (как не важно, заполняет что или действительно код генерит...) BeanInfo.
VD>> Главное, что ты не можешь переплюнуть логику компонента реализованного через нестандартные реализации этой лабуды, а занчит обязан все это читать через все эит BeanInfo. AVK>Нет, BeanInfo нужен только дизайнеру. Так что ничего читать ты не обязан. Даже если ты пишешь свой дизайнер то используя интроспектор можешь не обращать внимания на все эти инфы. А можешь написать своего интроспектора который вместо классов будет использовать текстовые файлы.
Да пофигу кому он нужен! Тебе говрят, что была сделана надстройка над компонентной моделью. Введение BeanInfo приводит к тому, что нельзя гарантировать правильной работы с информацией о типах компонента если пользоваться технологимяи отличными от BeanInfo. Гигкость эта гребаная чисто гипотетическая, а нарушение компонентной модели явное.
AVK>Алгоритм в файл не запихнешь.
Красиво сказано, но... длл-и exe-шинки и .class-файлы доказывают обратное. ;)
AVK> А потом наследство старой джавы — в plain text не очень то запихнешь, а xml-парсер появился только в 1.4.
Что наследство я не спорю. Но наследство очень левое. К тому же описание одного класса спокойно пихается в плоский файл формата:
a=b
c=f
Вложенные классы просто описываем в отдельных файлах. Если нужна функциональность какая (как ты говоришь алгоритм), то в текстовом файле описываем ссылку на Явовский класс. Короче, так же как в .Net, только атрибуты эмулируем в отдельных файлах. Да на атрибутах красивее, но все же лучне чем пахабить стройность компонентной модели.
AVK>А насчет лучше — чем лучше? Хотя бы 1 причину приведи.
Стройность компонентной модели. Остольные: совместимость продуктов разных производителей, универсальность (не нужно было бы Ё-бобы изобритать, любой класс Ё-боб если для визуальных компонентов реализуем дополнительный интерфейс — IControl)...
VD>>Насколько я знаю, их можно реализовывать самостоятельно, а значит в объод двигаться нельзя. AVK>Можно. А учитывая то что есть исходники ВСЕЙ библиотеки можно сделать что угодно.
Заметь! Если для использования или понимания компонентной модели нужны исходники, то прямой ее назвать точно нельзя.
VD>> Т.е. даже появление атрибутов не приведет к изменению схемы. Ну, или снова будут гудеть о революции. AVK>Приведет к появлению параллельной. А старую объявят deprecated.
А если бы не випендирвались, а просто добавили свойства и обошлись бы решлекшоном (который для этого и делался), то огород городить не пришлось бы.
AVK>Совершенно верно, проще. Но джава не дотнет — у нее уже не первая версия, надо обеспечивать совместимость.
Кому надо? Мне нет. Тем более, что вон тот же Нэт с комом и Win32 API совместимость обеспечивает. Sun тоже не переломился бы. И вообще ты непоследователен, то про диприкэйтед, то про поддержку старых версий. Напомню, что ты споришь с моим утверждением, что в Ява кривая компонентная модель. Не бери пример с Z, не меняй обсуждаемую тему.
VD>>>> хотя CODEDOM с его недокументированностью получился тяжеловатым и молопонятным. AVK>>>Вот тут как раз и помогли бы исходники. VD>>Кто бы спрорил. Но лучши исходники и документация. :) AVK>Так на доку надо усилия прикладывать. Встречал в доке к дотнету фразу AVK>This type supports the .NET Framework infrastructure and is not intended to be used directly from your code. ? AVK>Думаешь откуда такое? В джаве подобного нет. Я думаю MS стремился как можно скорее релизнуть этот долгострой, и по причине нехватки времени не написал документацию или не проработал как следует интерфейсы, оставив их проработку на следующие версии.
Думаю, кроме времени и нехватик сил здесь били и старые (и уже не верные) сообажения сохранности своего ноухау.
По странному стечению обстоятельств закрытым оказался код не дублирующийся с Явским и в большинстве своем значительно превосхдящий все аналоги. То же CODEDOM — это скорее пощечина Дельфи и Борланду. Борланд примерно в это же время получил потент на "ту вэй тулс" по нашему дунаправленное изменение кода. :) Забавно они предявят этот патент MS-у, ведь формально VS.Net этот потент юзает, хотя и появилать до его регистрации. :)))
VD>>Дык это и есть главная особенность бобов. Я честно говоря думал Ё-джибя так же сделаны. AVK>Ничего похожего на beaninfo там нет. Все спецификации свойств прописываются в специальном xml файле, который зовется deployment descriptor. Т.е. как раз то что ты предлагал. Вот пример для наглядности (большой потому что из реального приложения, меньше не нашел, а коцать времени нет)
Ну, и это ты называешь нормальной ОО-моделью (когда есть два вида описания компонентов и все они никакого отншения к языку не имеют)?
AVK>>>Какой интерфейс? VD>>IComponent AVK>Ну почему же он ничего не делает? Он обеспечивает помощение Component в Container.
Нет он обеспечивает получение информации о контейнере. Но где в определение понятий компонент и контейнер слова о том что в контейнере нужен список объектов? Мжно было создать отдельный интерфейс типа IMyContainerInfo. Они кстити туда еще и диспоуз зафигачили.
Мириться с этим конечно можно. Но жаль. Хотя по сравнению с наворотами из Явы это просто мелочи.
AVK> Плюс является неким флажком указывающим что это компонент.
А вот этого и не нужно. Ты сам понимаешь, что не трудно наклепать код который будет делать компонент из любого public-класса .Net. Ведь все необходимое в нем есть. А доказательством тому служит явная пустота интерфейса IComponent. Достаточно его реализовать и ты можешь кидать класс на форму. Так что мешало просто сделать атрибут гворящий, что компонент расчитан на использование в визуальных средах?
VD>>Я честно говоря считаю, что это тоже ошибка. Любой класс должен быть компонентом если это позволяет система. В Нэт и Яве это возможно, но не реализовано. :( Причем в Яве худшая форма. AVK>Излишняя функциональность. Не всегда оно нужно.
Нет никакой излишности. Я уже говорил. IComponent формальность. По сути любой класс уже все умеет чтобы быть компонентом.
AVK>>>Ну так BeanInfo и PropertyEditor тоже опциональные.
Согласен. Но если ты пишишь компонентную среду, то эти оции будут ставить палки в колеса. Плевать что Ява самодостаточна все равно клепай BeanInfo криэйтор, а при анализе компонентов пользуйся BeanInfo. Короче, жизнь по спецификации. Причем по плахой спецификации.
Вот ответь мне, почему они не сделави EnterpriseBeanInfo? Ведь если развивать их логику, то так было бы лучше.
VD>>...Нет, в Яве по умолчанию создается умолчальная реализация всех этих BeanInfo и Introspector-ов, а уже она лезит к компонентам. AVK>Нет. Никакой реализации по умолчанию не создается. А интроспектор вобще синглтон. Я это точно знаю потому что в свое время ковырялся в исходниках интроспектора и точно знаю как он работает. Если хочешь вышлю тебе его исходник, сам посмотришь.
Я и без исходника скажу, что BeanInfo реализуется Introspector или отдельно и работает на базе некоторой структуры/массива или динамической генерации кода. Это и есть умолчальная реализация! Для меня как для клиента возращаются разные BeanInfo и я как клиент (ну или контейнер) обязан идти через них, так как иначе могу получить неправильный результат.
VD>>Получается явная замена рефлекшона. Ольтернатива для получения информации о типах. AVK>Не альтернатива а недоделанность рефлекшена, не позволяющая его методами получить нужную информацию. Атрибуты были бы уместнее, но Sun до них не додумался. Теперь додумается :)
Я уже говорил, что решлекшон недоделан из-за недоделанноси явы. Нет свойств нет их описания.
Так что это просто непоследовательность и плахой дизайн. Если орете что свойсва сакс, то и нефика их эмулировать внося хаос в компонентную архитектуру. А если строете стройную модель, то нефига вредничать. Вводите нужные по жизни свойства и перечисления в язык.
Короче, мне кажется, что по существу ты со мной согласен, но почему то как и Sun в случае свойств и пречислений вредничаешь. Но я тоже вредный и буду стоять на своем, как бы это ни было больно. :)
AVK>>>А его и нет, выделенного класса. Есть только интерфейсы. А базовые классы для EJB у каждого сервера свои. EJB вобще больше похожи на aspx чем на классы как таковые. VD>>Класное достижение! AVK>Чем тебе не нравиться? Там все очень иначе. Долго объяснять.
Я говрю, "Класное достижение!" создание двух противоричащих друг другу компонентных моделей. До этого разговора мое мнение о Яве было лучше. :shuffle:
AVK>У меня вот на работе Cel1000 не особо то тормозит. Видимо у тебя задачи такие.
И только у меня. Большинство коммерчиских задачь или полностью такие или имеют такие части.
Я думаю задача MS полностью заменить MSIL-ом ассемблер. Они отработали эту технику на VC7. Он теперь для оптимизации в .obj-ы не объектный код помещает, а свою версию MSIL-а! Далее становятся доступны оптимизации на уровня всего приложения. Вот только длл-ки мешаются. Так вот CLR потенциально может оптимизировать приложения на уровне запущенного процесса. При этом длл-ки уже являются не проблемой. Прикинь какие перспективы?!
Так что если я не ошибаюсь, то мы еще увидим Ворд, Ёксель и SQL-сервер работающий под CLR. Интересно что ты скажещь тогда. ;)
AVK>А ворд тормозит совсем по другой причине. Я думаю на офисе MS оправдывает свою репутацию. :(
Ну, тут ты стал бональным плевальщиком по MS. Ворд это все же лучший продукт в соей области. Если посмотреть на конкурентов, то они или критически менее фунциональны, или давально менее функциональны и в дабавок более тормозные. Думаю, если Sun всерьез бы влез на рынок офисных программ, глюки ворда исчезли бы сами собой. :)
VD>>Ты это MS или Sun-у раскажи. :) Вот они посмеются... Деньги есть везде. AVK>Сколько контор в штуках производит коробочный софт? Я думаю не очень много.
Многие. Но главное, что деньги есть везеде. Вот Гейтс долго расказывал, что рынок бизнес-софта его не интересуют потому как там мало денег, а теперь вот взял и купил Навижен (серую лошадку в сфере КИС и ЕРП). Теперь будет качать бабки и из бухгалтериий. :)
VD>>Врочем как и сложные задачи. Среда которая первая займет подовлющее большинство питательных ниш и будет победителем. Это как в стратегиях. AVK>Нельзя объять необъятное. Тебе достанется некий кусок рынка. И нужно выбрать оптимум чтобы сектор был с одной стороны достаточно велик чтобы приносить большие деньги но с другой стороны достаточно мал чтобы хватило сил его завоевать и удержать.
Это ты разсказываешь как фиговый игрок в стратегии (я не хочу оскорбть, я тоже фиговый). А MS с Sun это персоны борющиеся за первое место в абсолютном первенстве. У них просто под понятием рынок значится IT-сфера. Любой игрок средней руги знает, что есть тольо две победные стратегии. Первая — rush, игра на маментальные и полный снос протиника (как минимум ослабление противника до состояния, чтобы он не мог являться тебе конкурентоа). Втарая — захват ресурсов. Занял нишку... удержал... Противник занял нишку... а ты его из нее выбил. В конце концов у противника кончаются ресурсы и он отваливает. Все остальное тактика. Можно предукадать какую нишку будут выносить и сосредоточить свои войска в ней. Можно отдать нишку без боя, за то занять две других или одну но большую. А рержаться за одну дохлую нишу — это путь блохи. MS и Sun так играть не будут. Так что для победы им нужен тотальный (или привалирующий) контроль над всем уровнем. Блох они принцепяльно не будут сносить. Даже подкармливать будут и баит в союзника. Иначе MS сразу выиграет, а за выигрышь по законам штатов (да и всего остального мири) пологается расчленение. Мосмотри на мамашу Бэл. :)
VD>>Скорость разработки на том же VB6 ни чуть не ниже. Есть и другие примеры. Все важно в комплексе. AVK>Скорость проектирования и качество полученных решений ниже. Качество я имею ввиду в плане дальнейшего развития.
Чушь, скорость проектирования вообще ут не причем. Пректирвание есть пректирование. Там все одинаково абстрактно. А программировать на VB даже быстрее чем на Яве. С ОО плохо, но для создания конечных систем это не смертельно. По сути С# и VB.Net развивают достойные традиции (RAD-ости) VB 1.0, а все остальные продукты всего лишь назгребают открытую нишу. Кстати, дизайнер форм VB 1.0 это вовремя купленная на стороне идея. MS хранил эту идею несколько лет до появляения VB.
AVK>>>К примеру тот же развитый рефлекшн по сути замешает темплейты, естественно ценой быстродействия. VD>>Это разные вещи. AVK>Тем не менее функционал темплейтов через рефлекшн реализуем.
Нет. Ты можешь добиться того же эффекта как от применения шаблонов, но тай же функциональности внутри кода ты не получишь. Шаблоны упащают жизнь. Выигрыш в скороси получается не взамен простоте и безопастности, а бесплатно. Не забывай, кстати, о безопасности. Динамический полиморфизм еще и не типобезопасен. Компилятор не видет таких ошибок, а страдать будет конечный пользователь (на рантайме).
VD>>К тому же быстродействие и типобезопастность это главные выгоды от генерик-типов. AVK>Типобезовасность реализуема и без них.
А ну-ка, продемонстрируй мре типобезопастный полиморфизм без шаблонов?
Только не нужно создавать обертки над полиморфнми объектами. Эти обертки уже не будут полимрфными. И их придется создавать вручную (или кодогенератором).
VD>>Не вот тут вот все будет однозначно. Если конечно не будет сильных побочных эффектов, типа сильного замедления компиляции. AVK>А что будет с GC? С рефлекшеном? С сериализацией? С ремоутингом? Когда начинаешь думать о деталях становится страшно.
На ничего не будут. Ну, может улучшат малость. :)
На одной из PDC уже разавали варант CLR и .Net-компилятора который поддерживал шаблоны (только они их назвали дженерик-типы). Создатели этого чуда говорили, что им пришлось изменить MSIL и CLR, но сам дух системы остался.
Все что ты перечислил к делу не отностся. Все это всего лишь связано с рефлекшоном, и ты боишься, что решлекшон развалится потянув за собой остальное.
Так что же страшного принесут шаблоны?
Информация о типах малость расширится вместо реального типа некторые методы будут возвращать описание коворящие, что тип будет известен полько при подстановке в шаблон некоторого значения. Для экземпляров это значение уже будет известно, для классов все будет просто несколько абстрактно. Зато насколько все станет безопастнее, быстрее и гибче?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте VladD2, Вы писали:
VD>Здравствуйте AndrewVK, Вы писали:
AVK>>Ну в 10 раз только на очень определенных моментах. Суммарно раза в 1.5-2.
VD>1.5-2 это показатели для Явы 1.3 (вызванные как я понимаю в основном динамическим полиморфизмом).
В смысле? Я хотел сказать что JVM 1.1.8 в среднем в 1.5-2 раза медленнее JVM 1.3.
AVK>>Time critical задачи нельзя решать ни на тогдашней джаве ни на теперешнем дотнете.
VD>Вот игры, анализ сложный и т.п. пока что тяжело, но если эвулюция будет двигаться вперед, то и это станет возможным.
Я думаю что все игры кроме разве что шутеров уже вполне можно писать на дотнете.
VD>Как по твоему не лучше бы было положение Явы если у нее вместо свинга под виндовс была библиотека типа VCL или WinForms?
Думаю лучше.
AVK>>И еще — я уже не раз говорил, платформы вроде джавы и дотнета проектировались с прицелом не на кодера, а на дизайнера.
VD>Ту это уже ерунда. То, что нужно упрощать процесс программирования/проектирования, тут никто не спорит. Работать за ними все равно тем же кодерам. Ту же яву стали использовать когда программист смог получить в руки удобные инструменты типа ЯваБилдера, а ведь язык не изменился почти...
Да нет, тут ты не прав. А насчет кодеров — тут дело в акцентах. Если раньше часто поступались прозрачностью в угоду избавлению кодера от лишней работы и увеличению быстродействия то теперь чаще наоборот.
AVK>>В этом их принципиальное отличие от языков предыдущего поколения. VD>Я в 94 используя Gupta SQL Base имел почти все то, что мне предлагают в яве. Разве что переносимости небыло...
Не, это совсем не то.
VD>Высокоуровневые языки были давно. Возьми тот же VB. Можно плеваться сколько угодно, но ява в разы сложнее VB5-6, а приложения можно делать и на том, и на том.
А джава более низкоуровневый чем тот же VB. Дело не в высокоуровневости а в ориентированности. Попробуй тот же синглтон или коннектор реализовать на VB — на C# или джаве это будет куда элегантнее.
AVK>> Сейчас стало возможным пожертвовать эффективностью
VD>Пожертвовать эффективностю можно было всегда. Вот толко все же лучше этого не делать. Я уже где-то говорил, что все достойные программы пишутся на пределе возмжностей железа. Если процессор станет быстрее программы прсто станут интеллектуальнее и функциональные. И вообще хватит про жизнь за 33 мегогерцами...
Все в деньги упирается. Экономически выгоднее написать менее эффективное приложение, но за меньший срок, с меньшим количеством ошибок и легче модифицируемое и купить более мощное железо. Вобще — в настоящее время вопросы эффективности актуальны больше для коробочного софта, а для корпоративного главное чтобы можно было купить компьютер который обеспечит приемлемое быстродействие.
VD>1. Мое определение компонента: Объект (класс) оформленный в виде отчуждаемого модуля содержащего все необходимое описание и т.п. для использования объекта за пределами компьютра на котором был создан объект. Компонент должен иметь возможность использования как компилирующими так и интерпритирующими средсвами. Компонент не должен требовать статического подключения и дополнительного описания (например, заголовочных файлов).
А причем здесь это?
VD>2. Ява обладает механизмами для того чтобы обеспечить компонентную разработку. Средства определения свойств не всчет, так как данная парадигма отрицается создателями языка (и платформы) как ересь.
Ну не так все серьезно. Но пока да, нет там этого.
VD>3. BeanInfo является дополнительным стандартом определения информации о типах.
Да.
VD>4. Самостоятельная реализация BeanInfo может вернуть информацию о типах отличную от той которую можн было бы получить с помощью рефлекшона.
Нет. Только дополнительную — иконки, описания и т.п.
VD>5. (Базируется на пункте 5.) Стандартизация BeanInfo заставляет использовать именно его для получения информации о бинах.
Поскольку предпосылки в п.4 неверны то и этот пункт неверен.
VD>6. Модель Ё-бинов сделана отличным от бинов и рефлекшона компонентной модели.
Да.
VD>7. (Основано на всех предыдущих пунктах) Компонентаная модель Явы непоследовательна, противоричива и не стройна.
Поскольку не все предпосылки верны то и вывод тоже не верен.
VD>8. Компонентная модель Нэта красива, стройна и почти не противоречива.
Компонент в дотнете и в джаве это несколько разные вещи. Да и нет в дотнете ничего на EJB похожего.
VD>>> В конце концов можно было бы с эмулировать свойства в простых текстовых файлах (все равно их используют). AVK>>Классы гибче. VD>Эта гибкость портит компонентную модель. Что, по-моему, дароже.
Спорное утверждение. Возможно. Мне тоже не очень нравится. Но имеет право на существование.
VD>Это как это "Introspector — никто там ничего не создает" Ты хоть вдумайся в свои влова "Сначала пытаются залезть через рефлекшн". Это означает, что Introspector читает рефлекшон и на лету создает реализацию (как не важно, заполняет что или действительно код генерит...) BeanInfo.
Нет, не пытается он ничего создавать. Просто возвращает информацию о бине, вне зависимости от наличия/отсутствия BeanInfo.
Проще говоря — любому бину можно безболезненно удалить его BeanInfo, работать он все равно будет.
VD>Да пофигу кому он нужен! Тебе говрят, что была сделана надстройка над компонентной моделью. Введение BeanInfo приводит к тому, что нельзя гарантировать правильной работы с информацией о типах компонента если пользоваться технологимяи отличными от BeanInfo. Гигкость эта гребаная чисто гипотетическая, а нарушение компонентной модели явное.
Что то какая то демагогия получается. Есть стандарт. Естественно отклонения от стандарта вызовут проблемы — все что на этот стандарт полагается работать не будет. Точно также и в дотнете ты обязан реализовать IComponent. Так что никакого нарушения я так и не увидел.
AVK>>Алгоритм в файл не запихнешь. VD>Красиво сказано, но... длл-и exe-шинки и .class-файлы доказывают обратное. ;)
Ну так BeanInfo то в итоге и генерит class-файл. Что не так то?
AVK>> А потом наследство старой джавы — в plain text не очень то запихнешь, а xml-парсер появился только в 1.4.
VD>Что наследство я не спорю. Но наследство очень левое. К тому же описание одного класса спокойно пихается в плоский файл формата: VD>
VD>a=b
VD>c=f
VD>
А ты вспомни про то что бывают вложенные классы например. Или что тип свойств тоже может быть классом. Вот к примеру один из методов BeanInfo
BeanInfo[] getAdditionalBeanInfo()
//This method allows a BeanInfo object to return an arbitrary collection of other BeanInfo objects that
//provide additional information on the current bean.
VD>Вложенные классы просто описываем в отдельных файлах. Если нужна функциональность какая (как ты говоришь алгоритм), то в текстовом файле описываем ссылку на Явовский класс. Короче, так же как в .Net, только атрибуты эмулируем в отдельных файлах. Да на атрибутах красивее, но все же лучне чем пахабить стройность компонентной модели.
Что то мне то что ты предложил не кажется намного лучше.
AVK>>А насчет лучше — чем лучше? Хотя бы 1 причину приведи.
VD>Стройность компонентной модели. Остольные: совместимость продуктов разных производителей, универсальность
А чем бины от разных производителей вдруг стали несовместимыми? Все там и так совместимо. А где хранить метаданные — в файле или скомпилированном классе не суть важно.
VD> (не нужно было бы Ё-бобы изобритать, любой класс Ё-боб если для визуальных компонентов реализуем дополнительный интерфейс — IControl)...
Это мы уже в VCL проходили. Нельзя так делать — для корпоративных компонент нужен отдельный механизм.
VD>>>Насколько я знаю, их можно реализовывать самостоятельно, а значит в объод двигаться нельзя. AVK>>Можно. А учитывая то что есть исходники ВСЕЙ библиотеки можно сделать что угодно. VD>Заметь! Если для использования или понимания компонентной модели нужны исходники, то прямой ее назвать точно нельзя.
Исходники нужны чтобы ее покорежить. А для использования исходники не нужны.
VD>Кому надо? Мне нет. Тем более, что вон тот же Нэт с комом и Win32 API совместимость обеспечивает. Sun тоже не переломился бы. И вообще ты непоследователен, то про диприкэйтед,
deprecated не означает что это не работает.
VD> то про поддержку старых версий. Напомню, что ты споришь с моим утверждением, что в Ява кривая компонентная модель. Не бери пример с Z, не меняй обсуждаемую тему.
Я обсуждаемую тему и не меняю. Я так до сих пор и не понял — чем конкретно BeanInfo хуже текстового файла? Слова вроде "компонентная модель кривая" ни о чем не говорят.
VD>Думаю, кроме времени и нехватик сил здесь били и старые (и уже не верные) сообажения сохранности своего ноухау.
Да какое там ноухау. Все это давно известно. JSP уже давно придумали.
VD>По странному стечению обстоятельств закрытым оказался код не дублирующийся с Явским и в большинстве своем значительно превосхдящий все аналоги.
Ну уж PageParser то аналог в джаве имеет.
VD> То же CODEDOM — это скорее пощечина Дельфи и Борланду. Борланд примерно в это же время получил потент на "ту вэй тулс" по нашему дунаправленное изменение кода. :) Забавно они предявят этот патент MS-у, ведь формально VS.Net этот потент юзает, хотя и появилать до его регистрации. :)))
Reverse engineering сто лет в обед.
VD>Ну, и это ты называешь нормальной ОО-моделью (когда есть два вида описания компонентов и все они никакого отншения к языку не имеют)?
То есть как это не имеют? А к чему они тогда имеют?
VD>Они кстити туда еще и диспоуз зафигачили.
Чтобы контейнер мог компоненты прибивать. Деструкторов то нет.
VD>Мириться с этим конечно можно. Но жаль. Хотя по сравнению с наворотами из Явы это просто мелочи.
Да нет в джаве никаких таких наворотов. Все там просто.
VD>А вот этого и не нужно. Ты сам понимаешь, что не трудно наклепать код который будет делать компонент из любого public-класса .Net. Ведь все необходимое в нем есть. А доказательством тому служит явная пустота интерфейса IComponent. Достаточно его реализовать и ты можешь кидать класс на форму. Так что мешало просто сделать атрибут гворящий, что компонент расчитан на использование в визуальных средах?
А бог его знает. Логичней было бы размечать атрибутами. Тут есть другая мысль — в самых первых разговорах про дотнет никто про атрибуты не упоминал. Может сама идея атрибутов пришла уже после того как компонентная модель была готова? Ну вроде того же using — вроде он есть но почти нигде не используется.
AVK>>>>Ну так BeanInfo и PropertyEditor тоже опциональные.
VD>Согласен. Но если ты пишишь компонентную среду, то эти оции будут ставить палки в колеса. Плевать что Ява самодостаточна все равно клепай BeanInfo криэйтор, а при анализе компонентов пользуйся BeanInfo.
Зачем? Все уже есть. Чем тебя интроспектор не устраивает?
VD>Короче, жизнь по спецификации. Причем по плахой спецификации.
Я так до сих пор и не понял — чем она конкретно плоха?
VD>Вот ответь мне, почему они не сделави EnterpriseBeanInfo? Ведь если развивать их логику, то так было бы лучше.
Я совсем не уверен что стоит объединять GUI компоненты и бизнес-компоненты. При внешней похожести у них на самом деле очень много отличий.
VD>Я и без исходника скажу, что BeanInfo реализуется Introspector или отдельно и работает на базе некоторой структуры/массива или динамической генерации кода. Это и есть умолчальная реализация!
Генерации кода там нет точно. Возвращается просто массив классов с известным интерфейсом.
VD>Для меня как для клиента возращаются разные BeanInfo и я как клиент (ну или контейнер) обязан идти через них, так как иначе могу получить неправильный результат.
Что то я себя идиотом чувствую. Есть класс-интроспектор. Он возвращает массив BeanInfo. Я его могу использовать как мне угодно. Что в этом плохого то? Просто еще один слой абстракции над рефлекшеном.
VD>Так что это просто непоследовательность и плахой дизайн. Если орете что свойсва сакс, то и нефика их эмулировать внося хаос в компонентную архитектуру. А если строете стройную модель, то нефига вредничать. Вводите нужные по жизни свойства и перечисления в язык.
Спор то начался о том что java beans не дублируют рефлекшн. А по поводу стройности — лично я не вижу никакой особой кривости, нормальная модель.
AVK>>Чем тебе не нравиться? Там все очень иначе. Долго объяснять. VD>Я говрю, "Класное достижение!" создание двух противоричащих друг другу компонентных моделей. До этого разговора мое мнение о Яве было лучше. :shuffle:
Вон ты о чем. Лучше две модели чем тащить недостатки старой в новую. Это, увы, путь любой платформы. Очень элегантная поначалу VCL к 6 версии разрослась до какого то уродца. Примерно тоже происходит и с джавой. И тоже самое будет с дотнетом.
AVK>>У меня вот на работе Cel1000 не особо то тормозит. Видимо у тебя задачи такие. VD>И только у меня. Большинство коммерчиских задачь или полностью такие или имеют такие части.
Странно, у меня вот тоже коммерческие задачи.
VD>Я думаю задача MS полностью заменить MSIL-ом ассемблер. Они отработали эту технику на VC7. Он теперь для оптимизации в .obj-ы не объектный код помещает, а свою версию MSIL-а! Далее становятся доступны оптимизации на уровня всего приложения. Вот только длл-ки мешаются. Так вот CLR потенциально может оптимизировать приложения на уровне запущенного процесса. При этом длл-ки уже являются не проблемой. Прикинь какие перспективы?!
Да давно эти перспективы известны. Вот только что то пока никак они себя не проявляют. JavaOS помнишь? И где она теперь?
VD>Так что если я не ошибаюсь, то мы еще увидим Ворд, Ёксель и SQL-сервер работающий под CLR. Интересно что ты скажещь тогда. ;)
Это да. Тут все нормально. Для последнего официально заявлено что в следущей версии хранимые процедуры будут работать в CLR. Вот это действительно интересно, а то развели бардак полнейший. У каждого сервера своя экзекутивная часть SQL. А здесь многоплатформенность реально нужна.
AVK>>А ворд тормозит совсем по другой причине. Я думаю на офисе MS оправдывает свою репутацию. :( VD>Ну, тут ты стал бональным плевальщиком по MS. Ворд это все же лучший продукт в соей области.
Да. Но лучше от этого он не становится.
VD> Если посмотреть на конкурентов, то они или критически менее фунциональны, или давально менее функциональны и в дабавок более тормозные. Думаю, если Sun всерьез бы влез на рынок офисных программ, глюки ворда исчезли бы сами собой. :)
А он пытается. Последний из могикан наверное.
VD>Многие. Но главное, что деньги есть везеде. Вот Гейтс долго расказывал, что рынок бизнес-софта его не интересуют потому как там мало денег,
Там много денег. Это он лукавил.
VD> а теперь вот взял и купил Навижен (серую лошадку в сфере КИС и ЕРП).
Кто такая навижн я знаю. И это отнюдь не серая лошадка. Axapta лучшая в Европе КИС. А ветку Attain они прикроют.
VD>Теперь будет качать бабки и из бухгалтериий. :)
Давно пора. Аксапту кстати будут переписывать под дотнет.
VD>Это ты разсказываешь как фиговый игрок в стратегии (я не хочу оскорбть, я тоже фиговый). А MS с Sun это персоны борющиеся за первое место в абсолютном первенстве. У них просто под понятием рынок значится IT-сфера. Любой игрок средней руги знает, что есть тольо две победные стратегии. Первая — rush, игра на маментальные и полный снос протиника (как минимум ослабление противника до состояния, чтобы он не мог являться тебе конкурентоа). Втарая — захват ресурсов. Занял нишку... удержал... Противник занял нишку... а ты его из нее выбил. В конце концов у противника кончаются ресурсы и он отваливает. Все остальное тактика. Можно предукадать какую нишку будут выносить и сосредоточить свои войска в ней. Можно отдать нишку без боя, за то занять две других или одну но большую. А рержаться за одну дохлую нишу — это путь блохи. MS и Sun так играть не будут. Так что для победы им нужен тотальный (или привалирующий) контроль над всем уровнем.
К счастью даже у MS не получится поиметь весь софтовый рынок. А так все правильно. Я не о стратегии. Просто если попытаться создать продукт покрывающий все ниши то получится г. И никто этого и не делает. Разные ниши завоевываются разными продуктами.
VD>Чушь, скорость проектирования вообще ут не причем. Пректирвание есть пректирование. Там все одинаково абстрактно.
Вот только абстракции все же должны опираться на особенности платформы. Если нет рефлекшена сразу большой кусок объектных моделей становится нереализуемым или реализуемым так что овчинка не стоит выделки.
VD> А программировать на VB даже быстрее чем на Яве.
Так я о том и говорю. Кодинг на новых платформах не особенно лучше старых.
VD> С ОО плохо, но для создания конечных систем это не смертельно.
Для больших систем (вроде того же КИС) — почти смертельно, особенно в плане развития.
VD> По сути С# и VB.Net развивают достойные традиции (RAD-ости) VB 1.0, а все остальные продукты всего лишь назгребают открытую нишу.
Нет. К достойным наследникам можно отнести WinForms, отчасти ASP.NET.
VD> Кстати, дизайнер форм VB 1.0 это вовремя купленная на стороне идея. MS хранил эту идею несколько лет до появляения VB.
Напомнить FoxBase? Тогда еще виндюков не было, не то что VB.
AVK>>А что будет с GC? С рефлекшеном? С сериализацией? С ремоутингом? Когда начинаешь думать о деталях становится страшно. VD>На ничего не будут. Ну, может улучшат малость. :)
Влад, для подобных конструкций надо ручками дописывать код и обрабатывать темплейты как отдельный случай. И это надо сделать во всей библиотеке. С одной стороны неполиморфность это конечно хорошо, но с другой стороны это ведь главная прелесть ООП, и весь полиморфный код придется переписывать. Это огромная работа.
VD>На одной из PDC уже разавали варант CLR и .Net-компилятора который поддерживал шаблоны (только они их назвали дженерик-типы). Создатели этого чуда говорили, что им пришлось изменить MSIL и CLR, но сам дух системы остался.
Вот вот. А библиотеки они наверное почти и не правили. Добавить в язык можно.
VD>Все что ты перечислил к делу не отностся. Все это всего лишь связано с рефлекшоном, и ты боишься, что решлекшон развалится потянув за собой остальное.
Развалится не только рефлекшн. Точно развалится например ado.net — его подсистема преобразования датасетов к модели хранилища данных. В дотнете ведь даже простые типы полифорфны. А тут темплейты. Это будет особый случай вроде массивов.
VD>Так что же страшного принесут шаблоны?
Они могут привнести тучу глюков. Потому ни Sun ни MS особо не стремятся пока их добавлять.
VD>Информация о типах малость расширится вместо реального типа некторые методы будут возвращать описание коворящие, что тип будет известен полько при подстановке в шаблон некоторого значения.
Представь что будет с полиморфным кодом. Темплейты придется обрабатывать как особый случай.
Здравствуйте VladD2, Вы писали:
VD>>В Нэте тоже ввели интерфейс, но он вообще ничего не делает. AVK>>>>Какой интерфейс? VD>>>IComponent AVK>>Ну почему же он ничего не делает? Он обеспечивает помощение Component в Container.
VD>Нет он обеспечивает получение информации о контейнере. Но где в определение понятий компонент и контейнер слова о том что в контейнере нужен список объектов? Мжно было создать отдельный интерфейс типа IMyContainerInfo. Они кстити туда еще и диспоуз зафигачили.
VD>Мириться с этим конечно можно. Но жаль. Хотя по сравнению с наворотами из Явы это просто мелочи.
AVK>> Плюс является неким флажком указывающим что это компонент.
VD>А вот этого и не нужно. Ты сам понимаешь, что не трудно наклепать код который будет делать компонент из любого public-класса .Net. Ведь все необходимое в нем есть. А доказательством тому служит явная пустота интерфейса IComponent.
Это не пустота это тоненькая ниточка по можно вытягивать другие компоненты из того же контейнера, добавлять, удалять их.
VD>Достаточно его реализовать и ты можешь кидать класс на форму. Так что мешало просто сделать атрибут гворящий, что компонент расчитан на использование в визуальных средах? VD>>>Я честно говоря считаю, что это тоже ошибка. Любой класс должен быть компонентом если это позволяет система. В Нэт и Яве это возможно, но не реализовано. Причем в Яве худшая форма.
Так получится только компонент не знающий о контейнере, иногда этого достаточно но для сложных вещей нет.
VD>Нет никакой излишности. Я уже говорил. IComponent формальность. По сути любой класс уже все умеет чтобы быть компонентом.
Да не такая уж и формальность.
У компонентов такая фунуциональность, что без дополнительного интерфейса не обойтись.
Компонент должен иметь ссылку на контейнер чтобы в нем ковыряться, и просматривать другие компоненты из того же контейнера. Из тройки IComponent,ISite,IContainer бесполезным можно назвать только ISite от этого уровня косвенности еще можно было бы избавиться, можно было бы дать компоненту ссылку на сам IContainer.
ZEN>Всего: 36.92Mb -- вот сколько счастья для обычного пользователя!!!!
Люди, да че вы давитесь за 30Метров ?
Места на диске у узера нет ?
Так снесите все игрушки, сразу под гиг освободится...
А если еще инспекция по защите авторских прав нагрянет,
так в лучшем случае ничего кроме Виндов и оффиса не останется.
По моему, главно что бы было быстро
А узеру от программы нужны две вещи, форма ввода и отчеты... и чем проще, тем лучше...
А все остальное — это от лешего.
Здравствуйте AndrewVK, Вы писали:
VD>>1.5-2 это показатели для Явы 1.3 (вызванные как я понимаю в основном динамическим полиморфизмом). AVK>В смысле? Я хотел сказать что JVM 1.1.8 в среднем в 1.5-2 раза медленнее JVM 1.3.
В смысле в сравнении с VC7, Intel C++ или Delphi 6.
К тому же ты в прошлый раз вроде о 1.1.6 говорил. ;) Хотя и в данные слова верится с трудом. У тебя 1.1.8 остался? Попробуй шустрика на нем и 1.3.
VD>>Вот игры, анализ сложный и т.п. пока что тяжело, но если эвулюция будет двигаться вперед, то и это станет возможным. AVK>Я думаю что все игры кроме разве что шутеров уже вполне можно писать на дотнете.
Тогда глянь на WC3. Он хоть и стратегия, но идет на пределе железа. Причем чем круче железо, тем лучше идет. Процессор всегда есть чем занять...
VD>>Как по твоему не лучше бы было положение Явы если у нее вместо свинга под виндовс была библиотека типа VCL или WinForms? AVK>Думаю лучше.
Вот и я о том же. Думаю в AWT нужно было исправлять, только ламерство дизайнеров и безсистемность. Сама идея (надстройка над кодом ОС) была правильной. Особенно если считать количество десктопа на виндовс. :)
AVK>Да нет, тут ты не прав. А насчет кодеров — тут дело в акцентах. Если раньше часто поступались прозрачностью в угоду избавлению кодера от лишней работы и увеличению быстродействия то теперь чаще наоборот.
Ну, тогда вспомни Клипер, VB, Gupta, PowerDesigner и т.п.
AVK>>>В этом их принципиальное отличие от языков предыдущего поколения. VD>>Я в 94 используя Gupta SQL Base имел почти все то, что мне предлагают в яве. Разве что переносимости небыло... AVK>Не, это совсем не то.
Ну, тебе видней. ;)
AVK>А джава более низкоуровневый чем тот же VB. Дело не в высокоуровневости а в ориентированности. Попробуй тот же синглтон или коннектор реализовать на VB — на C# или джаве это будет куда элегантнее.
А там обычно этго и не нужно. Тем более, что я это уже делал. :)
AVK>Все в деньги упирается. Экономически выгоднее написать менее эффективное приложение, но за меньший срок, с меньшим количеством ошибок и легче модифицируемое и купить более мощное железо.
Ну, по этим показателям VB6 будет бить Яву еще долго. :)))
AVK> Вобще — в настоящее время вопросы эффективности актуальны больше для коробочного софта, а для корпоративного главное чтобы можно было купить компьютер который обеспечит приемлемое быстродействие.
Последнее все же от части реализуемо на чем угодно, а от части просто утопия. По масштабированию VB6 опять таки делает Яву как катенке. (По-моему, на tpc.org я тебя уже отсылал?).
В общем, по твоим рассуждениям VB как раз подходит на облать лидера. И ты знаешь, я с тобой согласен. :) Он и по сей день держит лидерство по количеству созданного бизнес-софта. Но на бизнес-софте свет клином не сошолся. А MS алчет полного господства. Вот и пускай напрягаются. Причем если будет напрягаться и Sun, я буду только рад.
VD>>1. Мое определение компонента: Объект (класс) оформленный в виде отчуждаемого модуля содержащего все необходимое описание и т.п. для использования объекта за пределами компьютра на котором был создан объект. Компонент должен иметь возможность использования как компилирующими так и интерпритирующими средсвами. Компонент не должен требовать статического подключения и дополнительного описания (например, заголовочных файлов). AVK>А причем здесь это?
При том, что выводы нужно делать на прдпосылках. Следующие рассуждения основываются на этом предположении. К тому же это объясняет мои слова о том что любой класс в Яве или Нэте уже компонент.
VD>>2. Ява обладает механизмами для того чтобы обеспечить компонентную разработку. Средства определения свойств не всчет, так как данная парадигма отрицается создателями языка (и платформы) как ересь. AVK>Ну не так все серьезно. Но пока да, нет там этого.
Дык, это вроде и породило спор. :???:
VD>>3. BeanInfo является дополнительным стандартом определения информации о типах. AVK>Да.
VD>>4. Самостоятельная реализация BeanInfo может вернуть информацию о типах отличную от той которую можн было бы получить с помощью рефлекшона. AVK>Нет. Только дополнительную — иконки, описания и т.п.
Если п.3 верен, то автоматом должен быть верен и этот пункт. Так как если пасажир может выбрать два пути, то водитель должен иметь горючее на самый длинный из них.
VD>>5. (Базируется на пункте 5.) Стандартизация BeanInfo заставляет использовать именно его для получения информации о бинах. AVK>Поскольку предпосылки в п.4 неверны то и этот пункт неверен.
См. комментарий к п. 4. Забавно, что не смотря на цифру пять, ты все понял правильно. ;)
VD>>6. Модель Ё-бинов сделана отличным от бинов и рефлекшона компонентной модели. AVK>Да.
VD>>7. (Основано на всех предыдущих пунктах) Компонентаная модель Явы непоследовательна, противоричива и не стройна. AVK>Поскольку не все предпосылки верны то и вывод тоже не верен.
Ну, если идти по логике. То (хотя я считаю, что п. 4, 5 верны) можно просто отбросить те пункты которые тебе не нравятся (они картины не изменяют). Хотя, по-моему, я прав.
VD>>8. Компонентная модель Нэта красива, стройна и почти не противоречива.
AVK>Компонент в дотнете и в джаве это несколько разные вещи. Да и нет в дотнете ничего на EJB похожего.
На Ё-бобы вообще похож любой компонент Нэта. Все транзакционности реализуются серверами. Засунь класс в COM+ и ты получишь сравнимую функциональность. Запросов по объектам конечно не сделаешь, но для этого есть ADO.Net и DataSet. По другому, но тоже самое. Зато быстрее и не коверкает компонентной модели.
VD>>Эта гибкость портит компонентную модель. Что, по-моему, дароже. AVK>Спорное утверждение. Возможно. Мне тоже не очень нравится. Но имеет право на существование.
На существование имеет право все что существует. Вот толко мне нарвятся все красивое и гибкое.
VD>>Это как это "Introspector — никто там ничего не создает" Ты хоть вдумайся в свои влова "Сначала пытаются залезть через рефлекшн". Это означает, что Introspector читает рефлекшон и на лету создает реализацию (как не важно, заполняет что или действительно код генерит...) BeanInfo. AVK>Нет, не пытается он ничего создавать. Просто возвращает информацию о бине, вне зависимости от наличия/отсутствия BeanInfo. AVK>Проще говоря — любому бину можно безболезненно удалить его BeanInfo, работать он все равно будет.
Не всегда. И не везде. Раз есть BeanInfo, занчит его будут использовать. А раз будут, значит без него не обойтись. Короче, задаю вопрос еще раз... Если BeanInfo так хорошь, то почему его не использовали в Ё-бабах?
VD>>Да пофигу кому он нужен! Тебе говрят, что была сделана надстройка над компонентной моделью. Введение BeanInfo приводит к тому, что нельзя гарантировать правильной работы с информацией о типах компонента если пользоваться технологимяи отличными от BeanInfo. Гигкость эта гребаная чисто гипотетическая, а нарушение компонентной модели явное. AVK>Что то какая то демагогия получается.
А что делать, если ты игнорируешь прямые утверждения? К тому же это не демогогия, а чисто логическое заключение. Просто я попытался сделать так, чтобы обсурдность его отрицания была заметна не вооруженным взглядом.
AVK>Есть стандарт. Естественно отклонения от стандарта вызовут проблемы — все что на этот стандарт полагается работать не будет. Точно также и в дотнете ты обязан реализовать IComponent. Так что никакого нарушения я так и не увидел.
IComponent не подминяет технику взоимодействия с компонентом. Он добавляет (не нужные, на мой взгляд) возможности, а BeanInfo частично дублирует рефлекшен. По твоему, что, нельзя создать ситуацию когда полученная черз рефлекшен информация (я не говорю о свойсвтвах) будет отличаться от аналогичной полученной черз BeanInfo?
AVK>>>Алгоритм в файл не запихнешь. VD>>Красиво сказано, но... длл-и exe-шинки и .class-файлы доказывают обратное. ;) AVK>Ну так BeanInfo то в итоге и генерит class-файл. Что не так то?
Ну, как минимум твое утверждение "Алгоритм в файл не запихнешь.". :) Да и странно... BeanInfo призван выдвать информацию о типах через свой интерфейс. Зачем ему чтото генерить? Можте это это кто другой для него что генерит?
AVK>А ты вспомни про то что бывают вложенные классы например.
Выложи их описание в отдельный файл.
AVK>Или что тип свойств тоже может быть классом.
Я уже сказал, что это будет отдельный класс. Который будет описан в отдельном файле. Как ты понимаешь иерархических классов не бывает.
AVK>Вот к примеру один из методов BeanInfo
AVK>
AVK> BeanInfo[] getAdditionalBeanInfo()
AVK> //This method allows a BeanInfo object to return an arbitrary collection of other BeanInfo objects that
AVK> //provide additional information on the current bean.
AVK>
Ну? Форменная глупость! Зачем она нужна? Сделанна только ради свойств. :(
VD>>Вложенные классы просто описываем в отдельных файлах. Если нужна функциональность какая (как ты говоришь алгоритм), то в текстовом файле описываем ссылку на Явовский класс. Короче, так же как в .Net, только атрибуты эмулируем в отдельных файлах. Да на атрибутах красивее, но все же лучне чем пахабить стройность компонентной модели. AVK>Что то мне то что ты предложил не кажется намного лучше.
Это избавило бы от дуближа функциональности, как в случае с BeanInfo. Но конечно не так модно как xml. :) И не так удобно как атрибуты.
AVK>>>А насчет лучше — чем лучше? Хотя бы 1 причину приведи.
VD>>Стройность компонентной модели. Остольные: совместимость продуктов разных производителей, универсальность AVK>А чем бины от разных производителей вдруг стали несовместимыми? Все там и так совместимо. А где хранить метаданные — в файле или скомпилированном классе не суть важно.
Вот интересно если выдрать бины из ЯваБилдера и засунуть их в ____ (впиши сам), все из них будут работать? Да и дело в том, что не совместимы они с теми же Ё-бабами. Так как компонентная парадигма меняется. Короче, BeanInfo примочка. Ты уж или покажи зачем она нужноа, или хватит спорить.
VD>> (не нужно было бы Ё-бобы изобритать, любой класс Ё-боб если для визуальных компонентов реализуем дополнительный интерфейс — IControl)... AVK>Это мы уже в VCL проходили. Нельзя так делать — для корпоративных компонент нужен отдельный механизм.
Я не вострги от VCL, но с компонентной архитектурой там лучше. :-/
VD>>Заметь! Если для использования или понимания компонентной модели нужны исходники, то прямой ее назвать точно нельзя. AVK>Исходники нужны чтобы ее покорежить. А для использования исходники не нужны.
Заметь! Значит их нужно корежить. :)
VD>>Кому надо? Мне нет. Тем более, что вон тот же Нэт с комом и Win32 API совместимость обеспечивает. Sun тоже не переломился бы. И вообще ты непоследователен, то про диприкэйтед, AVK>deprecated не означает что это не работает.
Да. Красный свет тоже не означает, что идти нельзя. Просто злые дятьки насували светофоров. :)
VD>> то про поддержку старых версий. Напомню, что ты споришь с моим утверждением, что в Ява кривая компонентная модель. Не бери пример с Z, не меняй обсуждаемую тему. AVK>Я обсуждаемую тему и не меняю. Я так до сих пор и не понял — чем конкретно BeanInfo хуже текстового файла? Слова вроде "компонентная модель кривая" ни о чем не говорят.
Я уже задолбался об этом говрить. :( К тому же текстовый файл (как в Ё-бинах) это тоже полумеры. Атрибуты самый верный выход. Они себя показали еще в COM-е.
VD>>Думаю, кроме времени и нехватик сил здесь били и старые (и уже не верные) сообажения сохранности своего ноухау. AVK>Да какое там ноухау. Все это давно известно. JSP уже давно придумали.
JSP содрано с ASP. Да и не причем тут оно. КодДом самая передавая модель двунаправленной кодогенерации на сегодняшний день. В компонентной области MS тоже впереди.
VD>>По странному стечению обстоятельств закрытым оказался код не дублирующийся с Явским и в большинстве своем значительно превосхдящий все аналоги. AVK>Ну уж PageParser то аналог в джаве имеет.
Я вот не пойму. Ты серьезно считаешь, что Asp.Net это главное достижение .Net?
VD>> То же CODEDOM — это скорее пощечина Дельфи и Борланду. Борланд примерно в это же время получил потент на "ту вэй тулс" по нашему дунаправленное изменение кода. :) Забавно они предявят этот патент MS-у, ведь формально VS.Net этот потент юзает, хотя и появилать до его регистрации. :))) AVK>Reverse engineering сто лет в обед.
Назови хоть один продукт который моддерживает двунаправленную генерацию кода на нескольких языках и при этом мозволяет создавать встраиваемые генераторы кода для компонентов и их отдельных частей.
VD>>Ну, и это ты называешь нормальной ОО-моделью (когда есть два вида описания компонентов и все они никакого отншения к языку не имеют)? AVK>То есть как это не имеют? А к чему они тогда имеют?
К частной реализации одного класса (BeanInfo).
VD>>Они кстити туда еще и диспоуз зафигачили. AVK>Чтобы контейнер мог компоненты прибивать. Деструкторов то нет.
Ну, еще одна недоработка. :) Вот только почему ты считаешь, что прибивать нужно только то что реализует IComponent? К тому же это нужно если только есть анмэнэджед-ресурсы. Во многих случаях это не нужно.
AVK>А бог его знает. Логичней было бы размечать атрибутами. Тут есть другая мысль — в самых первых разговорах про дотнет никто про атрибуты не упоминал. Может сама идея атрибутов пришла уже после того как компонентная модель была готова? Ну вроде того же using — вроде он есть но почти нигде не используется.
Гы-гы. Ты явно COM-ом не занимался. Атрибутам уже 100 лет. Их только из VB использовать на прямую было нельзя. В COM были встроенные атрибуты и т.н. кастом. Да и про то что "в самых первых разговорах про дотнет никто про атрибуты не упоминал" ты тоже заблуждаешься. Еще названия .Net небыло, а атрибуты уже обсасывались как расширение тайп-инфо в новй версии т.н. COM+. Вот почитай:
Тем что я не лапти клепаю, а продукты которые компонентную архитектуру используют непосредственно. Мне нужна технология где я смогу сам делать контейнеры и не буду оглядываться на криворукость чужих программистов. :(
VD>>Короче, жизнь по спецификации. Причем по плахой спецификации. AVK>Я так до сих пор и не понял — чем она конкретно плоха?
Я уже сто раз говорил. Дублированием методов получения информации о типах и как следствие не последовательностью и кривизной компонентной модели.
VD>>Вот ответь мне, почему они не сделави EnterpriseBeanInfo? Ведь если развивать их логику, то так было бы лучше. AVK>Я совсем не уверен что стоит объединять GUI компоненты и бизнес-компоненты. При внешней похожести у них на самом деле очень много отличий.
Как у компонентов у них отличия нет. Есть такое понятие/абстракция компонент. Так вот, в реальном мире это понятие однозначно (я давал его поределение), а в яве их три штуки, и все разные.
VD>>Я и без исходника скажу, что BeanInfo реализуется Introspector или отдельно и работает на базе некоторой структуры/массива или динамической генерации кода. Это и есть умолчальная реализация! AVK>Генерации кода там нет точно. Возвращается просто массив классов с известным интерфейсом.
Ага тлько выдающий разную информацию при одинаковых параметрах. Эта информация дубляж решлекшона, и правда в том, что она была сделана только из-за того, что в сане есть недальновидные люди объявившие свойства злом. :( Если бы BeanInfo выдвал информацию только о мнимых свойствах, то я бы и слова не сказал, но они (явно для удобства) засунули туда все тайп-инфо.
VD>>Для меня как для клиента возращаются разные BeanInfo и я как клиент (ну или контейнер) обязан идти через них, так как иначе могу получить неправильный результат. AVK>Что то я себя идиотом чувствую. Есть класс-интроспектор. Он возвращает массив BeanInfo. Я его могу использовать как мне угодно. Что в этом плохого то? Просто еще один слой абстракции над рефлекшеном.
Ты просто всю жизнь жил со стороны пользователя компоненов и нонтейнеров, а я со стороны их разработчиков. Вот ты меня понять и не можешь. :(
VD>>Так что это просто непоследовательность и плахой дизайн. Если орете что свойсва сакс, то и нефика их эмулировать внося хаос в компонентную архитектуру. А если строете стройную модель, то нефига вредничать. Вводите нужные по жизни свойства и перечисления в язык. AVK>Спор то начался о том что java beans не дублируют рефлекшн. А по поводу стройности — лично я не вижу никакой особой кривости, нормальная модель.
Это же как не дублируют, если в них та же информация но в другом виде? Да если бы они всегда дублировали, это было бы пол биды. А ведь можно учудить... я это уже сто раз говорил.
AVK>>>Чем тебе не нравиться? Там все очень иначе. Долго объяснять. VD>>Я говрю, "Класное достижение!" создание двух противоричащих друг другу компонентных моделей. До этого разговора мое мнение о Яве было лучше. :shuffle:
AVK>Вон ты о чем. Лучше две модели чем тащить недостатки старой в новую.
Лучше одна новая.
AVK>Это, увы, путь любой платформы. Очень элегантная поначалу VCL к 6 версии разрослась до какого то уродца. Примерно тоже происходит и с джавой. И тоже самое будет с дотнетом.
Компонентная модель там не храмая. Многим нарвится и сама библиотека.
AVK>Да давно эти перспективы известны. Вот только что то пока никак они себя не проявляют. JavaOS помнишь? И где она теперь?
В чистом виде это будет не скоро. У явы прсто нет возможностей создать высокопроизводительную ОС. В .Net появилисб задатки, но и их пока мало. Тот же GC никуда негден в масштабах ОС. К тому же нужно время. Но у MS и Sun все еще впереди.
VD>>Так что если я не ошибаюсь, то мы еще увидим Ворд, Ёксель и SQL-сервер работающий под CLR. Интересно что ты скажещь тогда. ;) AVK>Это да. Тут все нормально. Для последнего официально заявлено что в следущей версии хранимые процедуры будут работать в CLR.
Нет. Пока все прозаичнее. Появится тлько возможность создания хранимых процедур на .Net, сам сервер пишется на сях, да и транзакт никто не отменит.
AVK> Вот это действительно интересно, а то развели бардак полнейший. У каждого сервера своя экзекутивная часть SQL. А здесь многоплатформенность реально нужна.
Гы. Для SQL2k есть апдэйт позволюющий писать SP на Яве. :) Так что...
VD>>Ну, тут ты стал бональным плевальщиком по MS. Ворд это все же лучший продукт в соей области. AVK>Да. Но лучше от этого он не становится.
В нем есть 2-3 бага которые третируют его на протяжении 4-х лет. Интересно сколько их станет если его перепишут на C#? :)
VD>> Если посмотреть на конкурентов, то они или критически менее фунциональны, или давально менее функциональны и в дабавок более тормозные. Думаю, если Sun всерьез бы влез на рынок офисных программ, глюки ворда исчезли бы сами собой. :) AVK>А он пытается. Последний из могикан наверное.
Вообще-то все конкуренты живы. Даже Лексикон. :)
VD>>Многие. Но главное, что деньги есть везеде. Вот Гейтс долго расказывал, что рынок бизнес-софта его не интересуют потому как там мало денег, AVK>Там много денег. Это он лукавил.
Не думаю, что лукавил. Ошибался, возможно, но врать то ему зачем?
VD>> а теперь вот взял и купил Навижен (серую лошадку в сфере КИС и ЕРП). AVK>Кто такая навижн я знаю. И это отнюдь не серая лошадка. Axapta лучшая в Европе КИС. А ветку Attain они прикроют.
Ну, это ты SAP. :)
VD>>Теперь будет качать бабки и из бухгалтериий. :) AVK>Давно пора. Аксапту кстати будут переписывать под дотнет.
Ее к чертовой мотери давно нужно было полностью переписывать. В прочем как и все остальные продукты в этой области. Пусть даже и не на Нэт или Яве...
AVK>К счастью даже у MS не получится поиметь весь софтовый рынок.
А-га. Но понадкусывать может. :)
AVK>А так все правильно. Я не о стратегии. Просто если попытаться создать продукт покрывающий все ниши то получится г. И никто этого и не делает. Разные ниши завоевываются разными продуктами.
Не. Вот как раз компонентные технологии и позвляют создавать универсальные продукты. Не ноа 100% но этого и не требуется. Я уже пытался делиться мыслями в этой области, но пока видимо недоходчиво.
AVK>Вот только абстракции все же должны опираться на особенности платформы.
Нет. Они именно для того и абстаркции, чтобы на них опирались, а не наоборот.
AVK>Если нет рефлекшена сразу большой кусок объектных моделей становится нереализуемым или реализуемым так что овчинка не стоит выделки.
Рефлекшон — это часть реализации компонентного подхода. Именно он отличает COM, Яву и .Net от многих других достойных, но проигрывающих технологий и чистота его (компонентного подхода) реализаци является критически важной. Sun-у нужно пересматривать свой подход. Драть правильные идеи (не деля их на урощующие ОО и нет) и придумывать новые. Так же ему нуно наращивать скоростные характеристики Явы. Вот тогда они еще с MS повоюют. Для MS это тоже справедливо.
VD>> А программировать на VB даже быстрее чем на Яве. AVK>Так я о том и говорю. Кодинг на новых платформах не особенно лучше старых.
Ошибаешся. Важно все. .Net тем и хорошь, что на C# и даже на VB.Net программировать еще проще чем на VB6. Иначе кому он был бы нужен?
VD>> С ОО плохо, но для создания конечных систем это не смертельно. AVK>Для больших систем (вроде того же КИС) — почти смертельно, особенно в плане развития.
А ты знаешь на чем тот же SAP создан?
VD>> По сути С# и VB.Net развивают достойные традиции (RAD-ости) VB 1.0, а все остальные продукты всего лишь назгребают открытую нишу. AVK>Нет. К достойным наследникам можно отнести WinForms, отчасти ASP.NET.
Я имел в виду .Net и VS.Net. Выразился плохо. Но сами языки тут тоже играют не малую роль. Без того самого компонентного подхода сделать все это было нельзя. А VB стал первым ориентированным на компоненты средством разработки. Сам язык тут конечно не причем, но концепции родились именно тогда.
VD>> Кстати, дизайнер форм VB 1.0 это вовремя купленная на стороне идея. MS хранил эту идею несколько лет до появляения VB. AVK>Напомнить FoxBase? Тогда еще виндюков не было, не то что VB.
Напомни. Что-то я там не припомню компонентов. ;) А рисовалки интерфейсов были и до FoxPro. VB стал первой средой где появился компонентный подход.
AVK>>>А что будет с GC? С рефлекшеном? С сериализацией? С ремоутингом? Когда начинаешь думать о деталях становится страшно. VD>>На ничего не будут. Ну, может улучшат малость. :) AVK>Влад, для подобных конструкций надо ручками дописывать код и обрабатывать темплейты как отдельный случай.
Нет. Нужно просто ввести в MSIL или байт-код Явы абстрактные операции, ну, и тайп-инфо расширить.
AVK> И это надо сделать во всей библиотеке.
Библиотеки нужно к чертям переписывать. Все классы-списков по крайней мере. Может и линкед-лист добавят. :)
AVK> С одной стороны неполиморфность это конечно хорошо, но с другой стороны это ведь главная прелесть ООП, и весь полиморфный код придется переписывать. Это огромная работа.
Дык, на то они и монстры!
VD>>На одной из PDC уже разавали варант CLR и .Net-компилятора который поддерживал шаблоны (только они их назвали дженерик-типы). Создатели этого чуда говорили, что им пришлось изменить MSIL и CLR, но сам дух системы остался. AVK>Вот вот. А библиотеки они наверное почти и не правили. Добавить в язык можно.
Это не входило в их задачи. Хотя могу соврать, так как сам этого чуда не видел.
AVK>Развалится не только рефлекшн. Точно развалится например ado.net — его подсистема преобразования датасетов к модели хранилища данных.
Это еще по чему? К тому же что ты под "моделью хранилища данных" понимаешь?
AVK> В дотнете ведь даже простые типы полифорфны. А тут темплейты. Это будет особый случай вроде массивов.
А никто полиморфности отменять не будет. Появятся универсальные типы, которые тоже смогут быть полиморфными. Но не только динамически, но и статически (на уровне парометризации). Очень даже может быть, что все это будет сильно отличаться от шаблнов С++-а.
VD>>Так что же страшного принесут шаблоны? AVK>Они могут привнести тучу глюков. Потому ни Sun ни MS особо не стремятся пока их добавлять.
Гы. Они как раз от глюков избавят, перенеся многие проверки из рантайма в стадию компиляции. Ну, а создавать новый код ни MS, ни Sun не привыкать.
VD>>Информация о типах малость расширится вместо реального типа некторые методы будут возвращать описание коворящие, что тип будет известен полько при подстановке в шаблон некоторого значения. AVK>Представь что будет с полиморфным кодом. Темплейты придется обрабатывать как особый случай.
Дык, а вчем проблема? Все в промежуточном коде, при создании типа шаблона уже не будет. Будет обычный класс. Только можно будет лучше оптимизировать код.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте VladD2, Вы писали:
VD>Здравствуйте AndrewVK, Вы писали:
VD>>>1.5-2 это показатели для Явы 1.3 (вызванные как я понимаю в основном динамическим полиморфизмом). AVK>>В смысле? Я хотел сказать что JVM 1.1.8 в среднем в 1.5-2 раза медленнее JVM 1.3.
VD>В смысле в сравнении с VC7, Intel C++ или Delphi 6.
VD>К тому же ты в прошлый раз вроде о 1.1.6 говорил. ;) Хотя и в данные слова верится с трудом. У тебя 1.1.8 остался? Попробуй шустрика на нем и 1.3.
VD>>>Вот игры, анализ сложный и т.п. пока что тяжело, но если эвулюция будет двигаться вперед, то и это станет возможным. AVK>>Я думаю что все игры кроме разве что шутеров уже вполне можно писать на дотнете.
VD>Тогда глянь на WC3. Он хоть и стратегия, но идет на пределе железа. Причем чем круче железо, тем лучше идет. Процессор всегда есть чем занять...
VD>>>Как по твоему не лучше бы было положение Явы если у нее вместо свинга под виндовс была библиотека типа VCL или WinForms? AVK>>Думаю лучше.
VD>Вот и я о том же. Думаю в AWT нужно было исправлять, только ламерство дизайнеров и безсистемность. Сама идея (надстройка над кодом ОС) была правильной. Особенно если считать количество десктопа на виндовс. :)
AVK>>Да нет, тут ты не прав. А насчет кодеров — тут дело в акцентах. Если раньше часто поступались прозрачностью в угоду избавлению кодера от лишней работы и увеличению быстродействия то теперь чаще наоборот.
VD>Ну, тогда вспомни Клипер, VB, Gupta, PowerDesigner и т.п.
AVK>>>>В этом их принципиальное отличие от языков предыдущего поколения. VD>>>Я в 94 используя Gupta SQL Base имел почти все то, что мне предлагают в яве. Разве что переносимости небыло... AVK>>Не, это совсем не то.
VD>Ну, тебе видней. ;)
AVK>>А джава более низкоуровневый чем тот же VB. Дело не в высокоуровневости а в ориентированности. Попробуй тот же синглтон или коннектор реализовать на VB — на C# или джаве это будет куда элегантнее.
VD>А там обычно этго и не нужно. Тем более, что я это уже делал. :)
AVK>>Все в деньги упирается. Экономически выгоднее написать менее эффективное приложение, но за меньший срок, с меньшим количеством ошибок и легче модифицируемое и купить более мощное железо.
VD>Ну, по этим показателям VB6 будет бить Яву еще долго. :)))
AVK>> Вобще — в настоящее время вопросы эффективности актуальны больше для коробочного софта, а для корпоративного главное чтобы можно было купить компьютер который обеспечит приемлемое быстродействие.
VD>Последнее все же от части реализуемо на чем угодно, а от части просто утопия. По масштабированию VB6 опять таки делает Яву как катенке. (По-моему, на tpc.org я тебя уже отсылал?).
VD>В общем, по твоим рассуждениям VB как раз подходит на облать лидера. И ты знаешь, я с тобой согласен. :) Он и по сей день держит лидерство по количеству созданного бизнес-софта. Но на бизнес-софте свет клином не сошолся. А MS алчет полного господства. Вот и пускай напрягаются. Причем если будет напрягаться и Sun, я буду только рад.
VD>>>1. Мое определение компонента: Объект (класс) оформленный в виде отчуждаемого модуля содержащего все необходимое описание и т.п. для использования объекта за пределами компьютра на котором был создан объект. Компонент должен иметь возможность использования как компилирующими так и интерпритирующими средсвами. Компонент не должен требовать статического подключения и дополнительного описания (например, заголовочных файлов). AVK>>А причем здесь это?
VD>При том, что выводы нужно делать на прдпосылках. Следующие рассуждения основываются на этом предположении. К тому же это объясняет мои слова о том что любой класс в Яве или Нэте уже компонент.
VD>>>2. Ява обладает механизмами для того чтобы обеспечить компонентную разработку. Средства определения свойств не всчет, так как данная парадигма отрицается создателями языка (и платформы) как ересь. AVK>>Ну не так все серьезно. Но пока да, нет там этого.
VD>Дык, это вроде и породило спор. :???:
VD>>>3. BeanInfo является дополнительным стандартом определения информации о типах. AVK>>Да.
VD>>>4. Самостоятельная реализация BeanInfo может вернуть информацию о типах отличную от той которую можн было бы получить с помощью рефлекшона. AVK>>Нет. Только дополнительную — иконки, описания и т.п.
VD>Если п.3 верен, то автоматом должен быть верен и этот пункт. Так как если пасажир может выбрать два пути, то водитель должен иметь горючее на самый длинный из них.
VD>>>5. (Базируется на пункте 5.) Стандартизация BeanInfo заставляет использовать именно его для получения информации о бинах. AVK>>Поскольку предпосылки в п.4 неверны то и этот пункт неверен.
VD>См. комментарий к п. 4. Забавно, что не смотря на цифру пять, ты все понял правильно. ;)
VD>>>6. Модель Ё-бинов сделана отличным от бинов и рефлекшона компонентной модели. AVK>>Да.
VD>>>7. (Основано на всех предыдущих пунктах) Компонентаная модель Явы непоследовательна, противоричива и не стройна. AVK>>Поскольку не все предпосылки верны то и вывод тоже не верен.
VD>Ну, если идти по логике. То (хотя я считаю, что п. 4, 5 верны) можно просто отбросить те пункты которые тебе не нравятся (они картины не изменяют). Хотя, по-моему, я прав.
VD>>>8. Компонентная модель Нэта красива, стройна и почти не противоречива.
AVK>>Компонент в дотнете и в джаве это несколько разные вещи. Да и нет в дотнете ничего на EJB похожего.
VD>На Ё-бобы вообще похож любой компонент Нэта. Все транзакционности реализуются серверами. Засунь класс в COM+ и ты получишь сравнимую функциональность. Запросов по объектам конечно не сделаешь, но для этого есть ADO.Net и DataSet. По другому, но тоже самое. Зато быстрее и не коверкает компонентной модели.
VD>>>Эта гибкость портит компонентную модель. Что, по-моему, дароже. AVK>>Спорное утверждение. Возможно. Мне тоже не очень нравится. Но имеет право на существование.
VD>На существование имеет право все что существует. Вот толко мне нарвятся все красивое и гибкое.
VD>>>Это как это "Introspector — никто там ничего не создает" Ты хоть вдумайся в свои влова "Сначала пытаются залезть через рефлекшн". Это означает, что Introspector читает рефлекшон и на лету создает реализацию (как не важно, заполняет что или действительно код генерит...) BeanInfo. AVK>>Нет, не пытается он ничего создавать. Просто возвращает информацию о бине, вне зависимости от наличия/отсутствия BeanInfo. AVK>>Проще говоря — любому бину можно безболезненно удалить его BeanInfo, работать он все равно будет.
VD>Не всегда. И не везде. Раз есть BeanInfo, занчит его будут использовать. А раз будут, значит без него не обойтись. Короче, задаю вопрос еще раз... Если BeanInfo так хорошь, то почему его не использовали в Ё-бабах?
VD>>>Да пофигу кому он нужен! Тебе говрят, что была сделана надстройка над компонентной моделью. Введение BeanInfo приводит к тому, что нельзя гарантировать правильной работы с информацией о типах компонента если пользоваться технологимяи отличными от BeanInfo. Гигкость эта гребаная чисто гипотетическая, а нарушение компонентной модели явное. AVK>>Что то какая то демагогия получается.
VD>А что делать, если ты игнорируешь прямые утверждения? К тому же это не демогогия, а чисто логическое заключение. Просто я попытался сделать так, чтобы обсурдность его отрицания была заметна не вооруженным взглядом.
AVK>>Есть стандарт. Естественно отклонения от стандарта вызовут проблемы — все что на этот стандарт полагается работать не будет. Точно также и в дотнете ты обязан реализовать IComponent. Так что никакого нарушения я так и не увидел.
VD>IComponent не подминяет технику взоимодействия с компонентом. Он добавляет (не нужные, на мой взгляд) возможности, а BeanInfo частично дублирует рефлекшен. По твоему, что, нельзя создать ситуацию когда полученная черз рефлекшен информация (я не говорю о свойсвтвах) будет отличаться от аналогичной полученной черз BeanInfo?
AVK>>>>Алгоритм в файл не запихнешь. VD>>>Красиво сказано, но... длл-и exe-шинки и .class-файлы доказывают обратное. ;) AVK>>Ну так BeanInfo то в итоге и генерит class-файл. Что не так то?
VD>Ну, как минимум твое утверждение "Алгоритм в файл не запихнешь.". :) Да и странно... BeanInfo призван выдвать информацию о типах через свой интерфейс. Зачем ему чтото генерить? Можте это это кто другой для него что генерит?
AVK>>А ты вспомни про то что бывают вложенные классы например.
VD>Выложи их описание в отдельный файл.
AVK>>Или что тип свойств тоже может быть классом.
VD>Я уже сказал, что это будет отдельный класс. Который будет описан в отдельном файле. Как ты понимаешь иерархических классов не бывает.
AVK>>Вот к примеру один из методов BeanInfo
AVK>>
AVK>> BeanInfo[] getAdditionalBeanInfo()
AVK>> //This method allows a BeanInfo object to return an arbitrary collection of other BeanInfo objects that
AVK>> //provide additional information on the current bean.
AVK>>
VD>Ну? Форменная глупость! Зачем она нужна? Сделанна только ради свойств. :(
VD>>>Вложенные классы просто описываем в отдельных файлах. Если нужна функциональность какая (как ты говоришь алгоритм), то в текстовом файле описываем ссылку на Явовский класс. Короче, так же как в .Net, только атрибуты эмулируем в отдельных файлах. Да на атрибутах красивее, но все же лучне чем пахабить стройность компонентной модели. AVK>>Что то мне то что ты предложил не кажется намного лучше.
VD>Это избавило бы от дуближа функциональности, как в случае с BeanInfo. Но конечно не так модно как xml. :) И не так удобно как атрибуты.
AVK>>>>А насчет лучше — чем лучше? Хотя бы 1 причину приведи.
VD>>>Стройность компонентной модели. Остольные: совместимость продуктов разных производителей, универсальность AVK>>А чем бины от разных производителей вдруг стали несовместимыми? Все там и так совместимо. А где хранить метаданные — в файле или скомпилированном классе не суть важно.
VD>Вот интересно если выдрать бины из ЯваБилдера и засунуть их в ____ (впиши сам), все из них будут работать? Да и дело в том, что не совместимы они с теми же Ё-бабами. Так как компонентная парадигма меняется. Короче, BeanInfo примочка. Ты уж или покажи зачем она нужноа, или хватит спорить.
VD>>> (не нужно было бы Ё-бобы изобритать, любой класс Ё-боб если для визуальных компонентов реализуем дополнительный интерфейс — IControl)... AVK>>Это мы уже в VCL проходили. Нельзя так делать — для корпоративных компонент нужен отдельный механизм.
VD>Я не вострги от VCL, но с компонентной архитектурой там лучше. :-/
VD>>>Заметь! Если для использования или понимания компонентной модели нужны исходники, то прямой ее назвать точно нельзя. AVK>>Исходники нужны чтобы ее покорежить. А для использования исходники не нужны.
VD>Заметь! Значит их нужно корежить. :)
VD>>>Кому надо? Мне нет. Тем более, что вон тот же Нэт с комом и Win32 API совместимость обеспечивает. Sun тоже не переломился бы. И вообще ты непоследователен, то про диприкэйтед, AVK>>deprecated не означает что это не работает.
VD>Да. Красный свет тоже не означает, что идти нельзя. Просто злые дятьки насували светофоров. :)
VD>>> то про поддержку старых версий. Напомню, что ты споришь с моим утверждением, что в Ява кривая компонентная модель. Не бери пример с Z, не меняй обсуждаемую тему. AVK>>Я обсуждаемую тему и не меняю. Я так до сих пор и не понял — чем конкретно BeanInfo хуже текстового файла? Слова вроде "компонентная модель кривая" ни о чем не говорят.
VD>Я уже задолбался об этом говрить. :( К тому же текстовый файл (как в Ё-бинах) это тоже полумеры. Атрибуты самый верный выход. Они себя показали еще в COM-е.
VD>>>Думаю, кроме времени и нехватик сил здесь били и старые (и уже не верные) сообажения сохранности своего ноухау. AVK>>Да какое там ноухау. Все это давно известно. JSP уже давно придумали.
VD>JSP содрано с ASP. Да и не причем тут оно. КодДом самая передавая модель двунаправленной кодогенерации на сегодняшний день. В компонентной области MS тоже впереди.
VD>>>По странному стечению обстоятельств закрытым оказался код не дублирующийся с Явским и в большинстве своем значительно превосхдящий все аналоги. AVK>>Ну уж PageParser то аналог в джаве имеет.
VD>Я вот не пойму. Ты серьезно считаешь, что Asp.Net это главное достижение .Net?
VD>>> То же CODEDOM — это скорее пощечина Дельфи и Борланду. Борланд примерно в это же время получил потент на "ту вэй тулс" по нашему дунаправленное изменение кода. :) Забавно они предявят этот патент MS-у, ведь формально VS.Net этот потент юзает, хотя и появилать до его регистрации. :))) AVK>>Reverse engineering сто лет в обед.
VD>Назови хоть один продукт который моддерживает двунаправленную генерацию кода на нескольких языках и при этом мозволяет создавать встраиваемые генераторы кода для компонентов и их отдельных частей.
VD>>>Ну, и это ты называешь нормальной ОО-моделью (когда есть два вида описания компонентов и все они никакого отншения к языку не имеют)? AVK>>То есть как это не имеют? А к чему они тогда имеют?
VD>К частной реализации одного класса (BeanInfo).
VD>>>Они кстити туда еще и диспоуз зафигачили. AVK>>Чтобы контейнер мог компоненты прибивать. Деструкторов то нет.
VD>Ну, еще одна недоработка. :) Вот только почему ты считаешь, что прибивать нужно только то что реализует IComponent? К тому же это нужно если только есть анмэнэджед-ресурсы. Во многих случаях это не нужно.
AVK>>А бог его знает. Логичней было бы размечать атрибутами. Тут есть другая мысль — в самых первых разговорах про дотнет никто про атрибуты не упоминал. Может сама идея атрибутов пришла уже после того как компонентная модель была готова? Ну вроде того же using — вроде он есть но почти нигде не используется.
VD>Гы-гы. Ты явно COM-ом не занимался. Атрибутам уже 100 лет. Их только из VB использовать на прямую было нельзя. В COM были встроенные атрибуты и т.н. кастом. Да и про то что "в самых первых разговорах про дотнет никто про атрибуты не упоминал" ты тоже заблуждаешься. Еще названия .Net небыло, а атрибуты уже обсасывались как расширение тайп-инфо в новй версии т.н. COM+. Вот почитай:
VD>http://www.microsoft.com/msj/defaultframe.asp?page=/msj/1197/complus.htm VD>http://www.microsoft.com/msj/defaultframe.asp?page=/msj/1297/complus2/complus2.htm
VD>>>Согласен. Но если ты пишишь компонентную среду, то эти оции будут ставить палки в колеса. Плевать что Ява самодостаточна все равно клепай BeanInfo криэйтор, а при анализе компонентов пользуйся BeanInfo. AVK>>Зачем? Все уже есть. Чем тебя интроспектор не устраивает?
VD>Тем что я не лапти клепаю, а продукты которые компонентную архитектуру используют непосредственно. Мне нужна технология где я смогу сам делать контейнеры и не буду оглядываться на криворукость чужих программистов. :(
VD>>>Короче, жизнь по спецификации. Причем по плахой спецификации. AVK>>Я так до сих пор и не понял — чем она конкретно плоха?
VD>Я уже сто раз говорил. Дублированием методов получения информации о типах и как следствие не последовательностью и кривизной компонентной модели.
VD>>>Вот ответь мне, почему они не сделави EnterpriseBeanInfo? Ведь если развивать их логику, то так было бы лучше. AVK>>Я совсем не уверен что стоит объединять GUI компоненты и бизнес-компоненты. При внешней похожести у них на самом деле очень много отличий.
VD>Как у компонентов у них отличия нет. Есть такое понятие/абстракция компонент. Так вот, в реальном мире это понятие однозначно (я давал его поределение), а в яве их три штуки, и все разные.
VD>>>Я и без исходника скажу, что BeanInfo реализуется Introspector или отдельно и работает на базе некоторой структуры/массива или динамической генерации кода. Это и есть умолчальная реализация! AVK>>Генерации кода там нет точно. Возвращается просто массив классов с известным интерфейсом. VD>Ага тлько выдающий разную информацию при одинаковых параметрах. Эта информация дубляж решлекшона, и правда в том, что она была сделана только из-за того, что в сане есть недальновидные люди объявившие свойства злом. :( Если бы BeanInfo выдвал информацию только о мнимых свойствах, то я бы и слова не сказал, но они (явно для удобства) засунули туда все тайп-инфо.
VD>>>Для меня как для клиента возращаются разные BeanInfo и я как клиент (ну или контейнер) обязан идти через них, так как иначе могу получить неправильный результат. AVK>>Что то я себя идиотом чувствую. Есть класс-интроспектор. Он возвращает массив BeanInfo. Я его могу использовать как мне угодно. Что в этом плохого то? Просто еще один слой абстракции над рефлекшеном.
VD>Ты просто всю жизнь жил со стороны пользователя компоненов и нонтейнеров, а я со стороны их разработчиков. Вот ты меня понять и не можешь. :(
VD>>>Так что это просто непоследовательность и плахой дизайн. Если орете что свойсва сакс, то и нефика их эмулировать внося хаос в компонентную архитектуру. А если строете стройную модель, то нефига вредничать. Вводите нужные по жизни свойства и перечисления в язык. AVK>>Спор то начался о том что java beans не дублируют рефлекшн. А по поводу стройности — лично я не вижу никакой особой кривости, нормальная модель.
VD>Это же как не дублируют, если в них та же информация но в другом виде? Да если бы они всегда дублировали, это было бы пол биды. А ведь можно учудить... я это уже сто раз говорил.
AVK>>>>Чем тебе не нравиться? Там все очень иначе. Долго объяснять. VD>>>Я говрю, "Класное достижение!" создание двух противоричащих друг другу компонентных моделей. До этого разговора мое мнение о Яве было лучше. :shuffle:
AVK>>Вон ты о чем. Лучше две модели чем тащить недостатки старой в новую.
VD>Лучше одна новая.
AVK>>Это, увы, путь любой платформы. Очень элегантная поначалу VCL к 6 версии разрослась до какого то уродца. Примерно тоже происходит и с джавой. И тоже самое будет с дотнетом.
VD>Компонентная модель там не храмая. Многим нарвится и сама библиотека.
AVK>>Да давно эти перспективы известны. Вот только что то пока никак они себя не проявляют. JavaOS помнишь? И где она теперь?
VD>В чистом виде это будет не скоро. У явы прсто нет возможностей создать высокопроизводительную ОС. В .Net появилисб задатки, но и их пока мало. Тот же GC никуда негден в масштабах ОС. К тому же нужно время. Но у MS и Sun все еще впереди.
VD>>>Так что если я не ошибаюсь, то мы еще увидим Ворд, Ёксель и SQL-сервер работающий под CLR. Интересно что ты скажещь тогда. ;) AVK>>Это да. Тут все нормально. Для последнего официально заявлено что в следущей версии хранимые процедуры будут работать в CLR.
VD>Нет. Пока все прозаичнее. Появится тлько возможность создания хранимых процедур на .Net, сам сервер пишется на сях, да и транзакт никто не отменит.
AVK>> Вот это действительно интересно, а то развели бардак полнейший. У каждого сервера своя экзекутивная часть SQL. А здесь многоплатформенность реально нужна.
VD>Гы. Для SQL2k есть апдэйт позволюющий писать SP на Яве. :) Так что...
VD>>>Ну, тут ты стал бональным плевальщиком по MS. Ворд это все же лучший продукт в соей области. AVK>>Да. Но лучше от этого он не становится.
VD>В нем есть 2-3 бага которые третируют его на протяжении 4-х лет. Интересно сколько их станет если его перепишут на C#? :)
VD>>> Если посмотреть на конкурентов, то они или критически менее фунциональны, или давально менее функциональны и в дабавок более тормозные. Думаю, если Sun всерьез бы влез на рынок офисных программ, глюки ворда исчезли бы сами собой. :) AVK>>А он пытается. Последний из могикан наверное.
VD>Вообще-то все конкуренты живы. Даже Лексикон. :)
VD>>>Многие. Но главное, что деньги есть везеде. Вот Гейтс долго расказывал, что рынок бизнес-софта его не интересуют потому как там мало денег, AVK>>Там много денег. Это он лукавил.
VD>Не думаю, что лукавил. Ошибался, возможно, но врать то ему зачем?
VD>>> а теперь вот взял и купил Навижен (серую лошадку в сфере КИС и ЕРП). AVK>>Кто такая навижн я знаю. И это отнюдь не серая лошадка. Axapta лучшая в Европе КИС. А ветку Attain они прикроют.
VD>Ну, это ты SAP. :)
VD>>>Теперь будет качать бабки и из бухгалтериий. :) AVK>>Давно пора. Аксапту кстати будут переписывать под дотнет.
VD>Ее к чертовой мотери давно нужно было полностью переписывать. В прочем как и все остальные продукты в этой области. Пусть даже и не на Нэт или Яве...
AVK>>К счастью даже у MS не получится поиметь весь софтовый рынок.
VD>А-га. Но понадкусывать может. :)
AVK>>А так все правильно. Я не о стратегии. Просто если попытаться создать продукт покрывающий все ниши то получится г. И никто этого и не делает. Разные ниши завоевываются разными продуктами.
VD>Не. Вот как раз компонентные технологии и позвляют создавать универсальные продукты. Не ноа 100% но этого и не требуется. Я уже пытался делиться мыслями в этой области, но пока видимо недоходчиво.
AVK>>Вот только абстракции все же должны опираться на особенности платформы.
VD>Нет. Они именно для того и абстаркции, чтобы на них опирались, а не наоборот.
AVK>>Если нет рефлекшена сразу большой кусок объектных моделей становится нереализуемым или реализуемым так что овчинка не стоит выделки.
VD>Рефлекшон — это часть реализации компонентного подхода. Именно он отличает COM, Яву и .Net от многих других достойных, но проигрывающих технологий и чистота его (компонентного подхода) реализаци является критически важной. Sun-у нужно пересматривать свой подход. Драть правильные идеи (не деля их на урощующие ОО и нет) и придумывать новые. Так же ему нуно наращивать скоростные характеристики Явы. Вот тогда они еще с MS повоюют. Для MS это тоже справедливо.
VD>>> А программировать на VB даже быстрее чем на Яве. AVK>>Так я о том и говорю. Кодинг на новых платформах не особенно лучше старых.
VD>Ошибаешся. Важно все. .Net тем и хорошь, что на C# и даже на VB.Net программировать еще проще чем на VB6. Иначе кому он был бы нужен?
VD>>> С ОО плохо, но для создания конечных систем это не смертельно. AVK>>Для больших систем (вроде того же КИС) — почти смертельно, особенно в плане развития.
VD>А ты знаешь на чем тот же SAP создан?
VD>>> По сути С# и VB.Net развивают достойные традиции (RAD-ости) VB 1.0, а все остальные продукты всего лишь назгребают открытую нишу. AVK>>Нет. К достойным наследникам можно отнести WinForms, отчасти ASP.NET.
VD>Я имел в виду .Net и VS.Net. Выразился плохо. Но сами языки тут тоже играют не малую роль. Без того самого компонентного подхода сделать все это было нельзя. А VB стал первым ориентированным на компоненты средством разработки. Сам язык тут конечно не причем, но концепции родились именно тогда.
VD>>> Кстати, дизайнер форм VB 1.0 это вовремя купленная на стороне идея. MS хранил эту идею несколько лет до появляения VB. AVK>>Напомнить FoxBase? Тогда еще виндюков не было, не то что VB.
VD>Напомни. Что-то я там не припомню компонентов. ;) А рисовалки интерфейсов были и до FoxPro. VB стал первой средой где появился компонентный подход.
AVK>>>>А что будет с GC? С рефлекшеном? С сериализацией? С ремоутингом? Когда начинаешь думать о деталях становится страшно. VD>>>На ничего не будут. Ну, может улучшат малость. :) AVK>>Влад, для подобных конструкций надо ручками дописывать код и обрабатывать темплейты как отдельный случай.
VD>Нет. Нужно просто ввести в MSIL или байт-код Явы абстрактные операции, ну, и тайп-инфо расширить.
AVK>> И это надо сделать во всей библиотеке.
VD>Библиотеки нужно к чертям переписывать. Все классы-списков по крайней мере. Может и линкед-лист добавят. :)
AVK>> С одной стороны неполиморфность это конечно хорошо, но с другой стороны это ведь главная прелесть ООП, и весь полиморфный код придется переписывать. Это огромная работа.
VD>Дык, на то они и монстры!
VD>>>На одной из PDC уже разавали варант CLR и .Net-компилятора который поддерживал шаблоны (только они их назвали дженерик-типы). Создатели этого чуда говорили, что им пришлось изменить MSIL и CLR, но сам дух системы остался. AVK>>Вот вот. А библиотеки они наверное почти и не правили. Добавить в язык можно.
VD>Это не входило в их задачи. Хотя могу соврать, так как сам этого чуда не видел.
AVK>>Развалится не только рефлекшн. Точно развалится например ado.net — его подсистема преобразования датасетов к модели хранилища данных.
VD>Это еще по чему? К тому же что ты под "моделью хранилища данных" понимаешь?
AVK>> В дотнете ведь даже простые типы полифорфны. А тут темплейты. Это будет особый случай вроде массивов.
VD>А никто полиморфности отменять не будет. Появятся универсальные типы, которые тоже смогут быть полиморфными. Но не только динамически, но и статически (на уровне парометризации). Очень даже может быть, что все это будет сильно отличаться от шаблнов С++-а.
VD>>>Так что же страшного принесут шаблоны? AVK>>Они могут привнести тучу глюков. Потому ни Sun ни MS особо не стремятся пока их добавлять.
VD>Гы. Они как раз от глюков избавят, перенеся многие проверки из рантайма в стадию компиляции. Ну, а создавать новый код ни MS, ни Sun не привыкать.
VD>>>Информация о типах малость расширится вместо реального типа некторые методы будут возвращать описание коворящие, что тип будет известен полько при подстановке в шаблон некоторого значения. AVK>>Представь что будет с полиморфным кодом. Темплейты придется обрабатывать как особый случай.
VD>Дык, а вчем проблема? Все в промежуточном коде, при создании типа шаблона уже не будет. Будет обычный класс. Только можно будет лучше оптимизировать код.
Здравствуйте VladD2, Вы писали:
VD>Здравствуйте AndrewVK, Вы писали:
VD>>>1.5-2 это показатели для Явы 1.3 (вызванные как я понимаю в основном динамическим полиморфизмом). AVK>>В смысле? Я хотел сказать что JVM 1.1.8 в среднем в 1.5-2 раза медленнее JVM 1.3.
VD>В смысле в сравнении с VC7, Intel C++ или Delphi 6.
VD>К тому же ты в прошлый раз вроде о 1.1.6 говорил. ;) Хотя и в данные слова верится с трудом. У тебя 1.1.8 остался? Попробуй шустрика на нем и 1.3.
Тесты Java2 vs. Delphi: http://www.beep.ru/~izen/projects/projects.html
См. "JavaTest" и "DelphiTest"
Результаты на сортировки более-менее одинаковы: кто-то в одних алгоритмах впереди, кто-то -- в других.
Результаты в вычислениях с плав.точкой просто потрясают.
VD>>>Вот игры, анализ сложный и т.п. пока что тяжело, но если эвулюция будет двигаться вперед, то и это станет возможным. AVK>>Я думаю что все игры кроме разве что шутеров уже вполне можно писать на дотнете.
VD>Тогда глянь на WC3. Он хоть и стратегия, но идет на пределе железа. Причем чем круче железо, тем лучше идет. Процессор всегда есть чем занять...
VD>>>Как по твоему не лучше бы было положение Явы если у нее вместо свинга под виндовс была библиотека типа VCL или WinForms? AVK>>Думаю лучше.
VD>Вот и я о том же. Думаю в AWT нужно было исправлять, только ламерство дизайнеров и безсистемность. Сама идея (надстройка над кодом ОС) была правильной. Особенно если считать количество десктопа на виндовс. :)
Swing -- просто библиотека GUI, независимая от ОС. Напишите свою -- будет ещё одна альтернатива. Кстати, есть SWT (http://www.eclipse.org/) -- системно-зависимая библиотека (как AWT), возможный конкурент Swing по компактности и быстродействию.
AVK>>Да нет, тут ты не прав. А насчет кодеров — тут дело в акцентах. Если раньше часто поступались прозрачностью в угоду избавлению кодера от лишней работы и увеличению быстродействия то теперь чаще наоборот.
VD>Ну, тогда вспомни Клипер, VB, Gupta, PowerDesigner и т.п.
AVK>>>>В этом их принципиальное отличие от языков предыдущего поколения. VD>>>Я в 94 используя Gupta SQL Base имел почти все то, что мне предлагают в яве. Разве что переносимости небыло... AVK>>Не, это совсем не то.
VD>Ну, тебе видней. ;)
AVK>>А джава более низкоуровневый чем тот же VB. Дело не в высокоуровневости а в ориентированности. Попробуй тот же синглтон или коннектор реализовать на VB — на C# или джаве это будет куда элегантнее.
VD>А там обычно этго и не нужно. Тем более, что я это уже делал. :)
AVK>>Все в деньги упирается. Экономически выгоднее написать менее эффективное приложение, но за меньший срок, с меньшим количеством ошибок и легче модифицируемое и купить более мощное железо.
VD>Ну, по этим показателям VB6 будет бить Яву еще долго. :)))
AVK>> Вобще — в настоящее время вопросы эффективности актуальны больше для коробочного софта, а для корпоративного главное чтобы можно было купить компьютер который обеспечит приемлемое быстродействие.
Не согласен. Есть промышленные приложения реального времени. Иногда (укладывается во временные рамки) Java подходит для этого из-за устойчивости (нет утечек памяти) и стабильности.
VD>Последнее все же от части реализуемо на чем угодно, а от части просто утопия. По масштабированию VB6 опять таки делает Яву как катенке. (По-моему, на tpc.org я тебя уже отсылал?).
VD>В общем, по твоим рассуждениям VB как раз подходит на облать лидера. И ты знаешь, я с тобой согласен. :) Он и по сей день держит лидерство по количеству созданного бизнес-софта. Но на бизнес-софте свет клином не сошолся. А MS алчет полного господства. Вот и пускай напрягаются. Причем если будет напрягаться и Sun, я буду только рад.
VD>>>1. Мое определение компонента: Объект (класс) оформленный в виде отчуждаемого модуля содержащего все необходимое описание и т.п. для использования объекта за пределами компьютра на котором был создан объект. Компонент должен иметь возможность использования как компилирующими так и интерпритирующими средсвами. Компонент не должен требовать статического подключения и дополнительного описания (например, заголовочных файлов).
Он и не требует. Можно НЕ ИСПОЛЬЗОВАТЬ BeanInfo, поставляемое с Java-компонентом, а обойтись стандартным Introspector-ом. JBuilder прекрасно включает в свою палитру визуального дизайнера любые классы и можно работать с ними без напряга, но если есть BeanInfo, то будут и иконки, и спец.редакторы свойств. :))
VD>При том, что выводы нужно делать на прдпосылках. Следующие рассуждения основываются на этом предположении. К тому же это объясняет мои слова о том что любой класс в Яве или Нэте уже компонент.
Все классы -- это компоненты -- да, но только в общем смысле этого слова.
VD>>>2. Ява обладает механизмами для того чтобы обеспечить компонентную разработку. Средства определения свойств не всчет, так как данная парадигма отрицается создателями языка (и платформы) как ересь. AVK>>Ну не так все серьезно. Но пока да, нет там этого.
Почему же "ересь"? Просто другой подход: скрываемые поля и специфицированные (Get..(), Set..(), Is..()) методы работы с ними. Вот так и никак иначе.
VD>Дык, это вроде и породило спор. :???:
VD>>>3. BeanInfo является дополнительным стандартом определения информации о типах. AVK>>Да.
VD>>>4. Самостоятельная реализация BeanInfo может вернуть информацию о типах отличную от той которую можн было бы получить с помощью рефлекшона. AVK>>Нет. Только дополнительную — иконки, описания и т.п.
BeanInfo может вернуть только ДОПОЛНИТЕЛЬНУЮ информацию.
VD>Если п.3 верен, то автоматом должен быть верен и этот пункт. Так как если пасажир может выбрать два пути, то водитель должен иметь горючее на самый длинный из них.
Нет. Нельзя сравнивать методологию MS (весь офис в одном флаконе и игрушки к системе) и Java. Это из другой жизни...:)
VD>>>5. (Базируется на пункте 5.) Стандартизация BeanInfo заставляет использовать именно его для получения информации о бинах. AVK>>Поскольку предпосылки в п.4 неверны то и этот пункт неверен.
Когда есть BeanInfo, используется BeanInfo. Когда нет BeanInfo, а срочно нужна информация о структуре класса, используется Introspector и Reflection.
VD>См. комментарий к п. 4. Забавно, что не смотря на цифру пять, ты все понял правильно. ;)
VD>>>6. Модель Ё-бинов сделана отличным от бинов и рефлекшона компонентной модели. AVK>>Да.
VD>>>7. (Основано на всех предыдущих пунктах) Компонентаная модель Явы непоследовательна, противоричива и не стройна. AVK>>Поскольку не все предпосылки верны то и вывод тоже не верен.
На вкус и цвет...
Меня, например, раздражает объектная модель Delphi VCL -- такой корявой структуры я больше нигде не видел.
VD>Ну, если идти по логике. То (хотя я считаю, что п. 4, 5 верны) можно просто отбросить те пункты которые тебе не нравятся (они картины не изменяют). Хотя, по-моему, я прав.
VD>>>8. Компонентная модель Нэта красива, стройна и почти не противоречива.
У вас такой вкус...:)
AVK>>Компонент в дотнете и в джаве это несколько разные вещи. Да и нет в дотнете ничего на EJB похожего.
VD>На Ё-бобы вообще похож любой компонент Нэта. Все транзакционности реализуются серверами. Засунь класс в COM+ и ты получишь сравнимую функциональность. Запросов по объектам конечно не сделаешь, но для этого есть ADO.Net и DataSet. По другому, но тоже самое. Зато быстрее и не коверкает компонентной модели.
VD>>>Эта гибкость портит компонентную модель. Что, по-моему, дароже. AVK>>Спорное утверждение. Возможно. Мне тоже не очень нравится. Но имеет право на существование.
VD>На существование имеет право все что существует. Вот толко мне нарвятся все красивое и гибкое.
Опять же, ваше личное мнение о красоте не всегда совпадает с мнениями других.
Спорить о красоте, в этом случае, глупо.
VD>>>Это как это "Introspector — никто там ничего не создает" Ты хоть вдумайся в свои влова "Сначала пытаются залезть через рефлекшн". Это означает, что Introspector читает рефлекшон и на лету создает реализацию (как не важно, заполняет что или действительно код генерит...) BeanInfo. AVK>>Нет, не пытается он ничего создавать. Просто возвращает информацию о бине, вне зависимости от наличия/отсутствия BeanInfo. AVK>>Проще говоря — любому бину можно безболезненно удалить его BeanInfo, работать он все равно будет.
VD>Не всегда. И не везде. Раз есть BeanInfo, занчит его будут использовать. А раз будут, значит без него не обойтись. Короче, задаю вопрос еще раз... Если BeanInfo так хорошь, то почему его не использовали в Ё-бабах?
Голословное утверждение. Приведите пример, когда срочно необходим BeanInfo, когда без него не обойтись.
VD>>>Да пофигу кому он нужен! Тебе говрят, что была сделана надстройка над компонентной моделью. Введение BeanInfo приводит к тому, что нельзя гарантировать правильной работы с информацией о типах компонента если пользоваться технологимяи отличными от BeanInfo. Гигкость эта гребаная чисто гипотетическая, а нарушение компонентной модели явное. AVK>>Что то какая то демагогия получается.
VD>А что делать, если ты игнорируешь прямые утверждения? К тому же это не демогогия, а чисто логическое заключение. Просто я попытался сделать так, чтобы обсурдность его отрицания была заметна не вооруженным взглядом.
AVK>>Есть стандарт. Естественно отклонения от стандарта вызовут проблемы — все что на этот стандарт полагается работать не будет. Точно также и в дотнете ты обязан реализовать IComponent. Так что никакого нарушения я так и не увидел.
VD>IComponent не подминяет технику взоимодействия с компонентом. Он добавляет (не нужные, на мой взгляд) возможности, а BeanInfo частично дублирует рефлекшен. По твоему, что, нельзя создать ситуацию когда полученная черз рефлекшен информация (я не говорю о свойсвтвах) будет отличаться от аналогичной полученной черз BeanInfo?
Можно, но зачем это нужно? BeanInfo, в отличие от прямого reflection, обеспечивает более "человеческий" уровень понимания свойств компонента.
AVK>>>>Алгоритм в файл не запихнешь. VD>>>Красиво сказано, но... длл-и exe-шинки и .class-файлы доказывают обратное. ;) AVK>>Ну так BeanInfo то в итоге и генерит class-файл. Что не так то?
VD>Ну, как минимум твое утверждение "Алгоритм в файл не запихнешь.". :) Да и странно... BeanInfo призван выдвать информацию о типах через свой интерфейс. Зачем ему чтото генерить? Можте это это кто другой для него что генерит?
AVK>>А ты вспомни про то что бывают вложенные классы например.
VD>Выложи их описание в отдельный файл.
AVK>>Или что тип свойств тоже может быть классом.
VD>Я уже сказал, что это будет отдельный класс. Который будет описан в отдельном файле. Как ты понимаешь иерархических классов не бывает.
AVK>>Вот к примеру один из методов BeanInfo
AVK>>
AVK>> BeanInfo[] getAdditionalBeanInfo()
AVK>> //This method allows a BeanInfo object to return an arbitrary collection of other BeanInfo objects that
AVK>> //provide additional information on the current bean.
AVK>>
VD>Ну? Форменная глупость! Зачем она нужна? Сделанна только ради свойств. :(
VD>>>Вложенные классы просто описываем в отдельных файлах. Если нужна функциональность какая (как ты говоришь алгоритм), то в текстовом файле описываем ссылку на Явовский класс. Короче, так же как в .Net, только атрибуты эмулируем в отдельных файлах. Да на атрибутах красивее, но все же лучне чем пахабить стройность компонентной модели. AVK>>Что то мне то что ты предложил не кажется намного лучше.
VD>Это избавило бы от дуближа функциональности, как в случае с BeanInfo. Но конечно не так модно как xml. :) И не так удобно как атрибуты.
AVK>>>>А насчет лучше — чем лучше? Хотя бы 1 причину приведи.
VD>>>Стройность компонентной модели. Остольные: совместимость продуктов разных производителей, универсальность AVK>>А чем бины от разных производителей вдруг стали несовместимыми? Все там и так совместимо. А где хранить метаданные — в файле или скомпилированном классе не суть важно.
VD>Вот интересно если выдрать бины из ЯваБилдера и засунуть их в ____ (впиши сам), все из них будут работать? Да и дело в том, что не совместимы они с теми же Ё-бабами. Так как компонентная парадигма меняется. Короче, BeanInfo примочка. Ты уж или покажи зачем она нужноа, или хватит спорить.
BeanInfo -- "примочка" для предоставления красочно-описанной информации о компоненте. Нужно для разработчика, чтобы было приятно и удобно работать со свойствами компонента во время разработки приложения.
VD>>> (не нужно было бы Ё-бобы изобритать, любой класс Ё-боб если для визуальных компонентов реализуем дополнительный интерфейс — IControl)... AVK>>Это мы уже в VCL проходили. Нельзя так делать — для корпоративных компонент нужен отдельный механизм.
VD>Я не вострги от VCL, но с компонентной архитектурой там лучше. :-/
Мне VCL не нравится. Но я же не кричу об этом на всю улицу.
VD>>>Заметь! Если для использования или понимания компонентной модели нужны исходники, то прямой ее назвать точно нельзя. AVK>>Исходники нужны чтобы ее покорежить. А для использования исходники не нужны.
VD>Заметь! Значит их нужно корежить. :)
VD>>>Кому надо? Мне нет. Тем более, что вон тот же Нэт с комом и Win32 API совместимость обеспечивает. Sun тоже не переломился бы. И вообще ты непоследователен, то про диприкэйтед, AVK>>deprecated не означает что это не работает. VD>Да. Красный свет тоже не означает, что идти нельзя. Просто злые дятьки насували светофоров. :)
deprecated-методы имеют в своём теле вызов "улучшенного" нового метода, так что они -- просто заглушки для использования старым кодом новых улучшенных функций.
VD>>> то про поддержку старых версий. Напомню, что ты споришь с моим утверждением, что в Ява кривая компонентная модель. Не бери пример с Z, не меняй обсуждаемую тему.
Когда это я менял тему?
AVK>>Я обсуждаемую тему и не меняю. Я так до сих пор и не понял — чем конкретно BeanInfo хуже текстового файла? Слова вроде "компонентная модель кривая" ни о чем не говорят.
VD>Я уже задолбался об этом говрить. :( К тому же текстовый файл (как в Ё-бинах) это тоже полумеры. Атрибуты самый верный выход. Они себя показали еще в COM-е.
VD>>>Думаю, кроме времени и нехватик сил здесь били и старые (и уже не верные) сообажения сохранности своего ноухау. AVK>>Да какое там ноухау. Все это давно известно. JSP уже давно придумали.
VD>JSP содрано с ASP. Да и не причем тут оно. КодДом самая передавая модель двунаправленной кодогенерации на сегодняшний день. В компонентной области MS тоже впереди.
Так ли? В том же JBuilder визуальный дизайнер полностью two-way-tools, обходится без двоичных ресурсных файлов (не читая картинок). Редактируешь текст -- получаешь в визуале, ворочаешь визуал -- получаешь текст.
А где MS? "Редактируйте" res-файлы только мышкой в дизайнере!
А Delphi -- это вообще убожество с DFM-описаниями форм! Чуть версия не та -- заново формочку строй.
VD>>>По странному стечению обстоятельств закрытым оказался код не дублирующийся с Явским и в большинстве своем значительно превосхдящий все аналоги. AVK>>Ну уж PageParser то аналог в джаве имеет.
VD>Я вот не пойму. Ты серьезно считаешь, что Asp.Net это главное достижение .Net?
VD>>> То же CODEDOM — это скорее пощечина Дельфи и Борланду. Борланд примерно в это же время получил потент на "ту вэй тулс" по нашему дунаправленное изменение кода. :) Забавно они предявят этот патент MS-у, ведь формально VS.Net этот потент юзает, хотя и появилать до его регистрации. :)))
Если CODEDOM -- это представление ресурсов визуальных форм в виде xml-дерева, то это реализовано в Java IDE NetBeans. Только это дерево полностью отчуждаемо от проекта.
AVK>>Reverse engineering сто лет в обед.
VD>Назови хоть один продукт который моддерживает двунаправленную генерацию кода на нескольких языках и при этом мозволяет создавать встраиваемые генераторы кода для компонентов и их отдельных частей.
Rational Rose, Together.
VD>>>Ну, и это ты называешь нормальной ОО-моделью (когда есть два вида описания компонентов и все они никакого отншения к языку не имеют)? AVK>>То есть как это не имеют? А к чему они тогда имеют?
VD>К частной реализации одного класса (BeanInfo).
VD>>>Они кстити туда еще и диспоуз зафигачили. AVK>>Чтобы контейнер мог компоненты прибивать. Деструкторов то нет.
VD>Ну, еще одна недоработка. :) Вот только почему ты считаешь, что прибивать нужно только то что реализует IComponent? К тому же это нужно если только есть анмэнэджед-ресурсы. Во многих случаях это не нужно.
AVK>>А бог его знает. Логичней было бы размечать атрибутами. Тут есть другая мысль — в самых первых разговорах про дотнет никто про атрибуты не упоминал. Может сама идея атрибутов пришла уже после того как компонентная модель была готова? Ну вроде того же using — вроде он есть но почти нигде не используется.
VD>Гы-гы. Ты явно COM-ом не занимался. Атрибутам уже 100 лет. Их только из VB использовать на прямую было нельзя. В COM были встроенные атрибуты и т.н. кастом. Да и про то что "в самых первых разговорах про дотнет никто про атрибуты не упоминал" ты тоже заблуждаешься. Еще названия .Net небыло, а атрибуты уже обсасывались как расширение тайп-инфо в новй версии т.н. COM+. Вот почитай:
VD>http://www.microsoft.com/msj/defaultframe.asp?page=/msj/1197/complus.htm VD>http://www.microsoft.com/msj/defaultframe.asp?page=/msj/1297/complus2/complus2.htm
VD>>>Согласен. Но если ты пишишь компонентную среду, то эти оции будут ставить палки в колеса. Плевать что Ява самодостаточна все равно клепай BeanInfo криэйтор, а при анализе компонентов пользуйся BeanInfo. AVK>>Зачем? Все уже есть. Чем тебя интроспектор не устраивает?
VD>Тем что я не лапти клепаю, а продукты которые компонентную архитектуру используют непосредственно. Мне нужна технология где я смогу сам делать контейнеры и не буду оглядываться на криворукость чужих программистов. :(
Вы системы разработки "клепаете" что-ли? Тогда, очевидно, в некоторые моменты понадобится использовать BeanInfo. Для "обычных" приложений BeanInfo излишне.
VD>>>Короче, жизнь по спецификации. Причем по плахой спецификации. AVK>>Я так до сих пор и не понял — чем о
на конкретно плоха?
VD>Я уже сто раз говорил. Дублированием методов получения информации о типах и как следствие не последовательностью и кривизной компонентной модели.
Не дублирование, но дополнение. Как вы это всё ещё не поймёте?
VD>>>Вот ответь мне, почему они не сделави EnterpriseBeanInfo? Ведь если развивать их логику, то так было бы лучше. AVK>>Я совсем не уверен что стоит объединять GUI компоненты и бизнес-компоненты. При внешней похожести у них на самом деле очень много отличий.
VD>Как у компонентов у них отличия нет. Есть такое понятие/абстракция компонент. Так вот, в реальном мире это понятие однозначно (я давал его поределение), а в яве их три штуки, и все разные.
VD>>>Я и без исходника скажу, что BeanInfo реализуется Introspector или отдельно и работает на базе некоторой структуры/массива или динамической генерации кода. Это и есть умолчальная реализация! AVK>>Генерации кода там нет точно. Возвращается просто массив классов с известным интерфейсом. VD>Ага тлько выдающий разную информацию при одинаковых параметрах. Эта информация дубляж решлекшона, и правда в том, что она была сделана только из-за того, что в сане есть недальновидные люди объявившие свойства злом. :( Если бы BeanInfo выдвал информацию только о мнимых свойствах, то я бы и слова не сказал, но они (явно для удобства) засунули туда все тайп-инфо.
VD>>>Для меня как для клиента возращаются разные BeanInfo и я как клиент (ну или контейнер) обязан идти через них, так как иначе могу получить неправильный результат. AVK>>Что то я себя идиотом чувствую. Есть класс-интроспектор. Он возвращает массив BeanInfo. Я его могу использовать как мне угодно. Что в этом плохого то? Просто еще один слой абстракции над рефлекшеном.
VD>Ты просто всю жизнь жил со стороны пользователя компоненов и нонтейнеров, а я со стороны их разработчиков. Вот ты меня понять и не можешь. :(
VD>>>Так что это просто непоследовательность и плахой дизайн. Если орете что свойсва сакс, то и нефика их эмулировать внося хаос в компонентную архитектуру. А если строете стройную модель, то нефига вредничать. Вводите нужные по жизни свойства и перечисления в язык. AVK>>Спор то начался о том что java beans не дублируют рефлекшн. А по поводу стройности — лично я не вижу никакой особой кривости, нормальная модель.
VD>Это же как не дублируют, если в них та же информация но в другом виде? Да если бы они всегда дублировали, это было бы пол биды. А ведь можно учудить... я это уже сто раз говорил.
AVK>>>>Чем тебе не нравиться? Там все очень иначе. Долго объяснять. VD>>>Я говрю, "Класное достижение!" создание двух противоричащих друг другу компонентных моделей. До этого разговора мое мнение о Яве было лучше. :shuffle:
AVK>>Вон ты о чем. Лучше две модели чем тащить недостатки старой в новую.
VD>Лучше одна новая.
AVK>>Это, увы, путь любой платформы. Очень элегантная поначалу VCL к 6 версии разрослась до какого то уродца. Примерно тоже происходит и с джавой. И тоже самое будет с дотнетом.
VD>Компонентная модель там не храмая. Многим нарвится и сама библиотека.
Мне нет. Swing на порядок стройнее и продуманней.
AVK>>Да давно эти перспективы известны. Вот только что то пока никак они себя не проявляют. JavaOS помнишь? И где она теперь?
Есть PDA с pure-JavaOS, работающие на Java-процессоре aJ-100 (по последним новостям из osp.ru http://www.osp.ru/news/hard/2002/07/03_01.htm
"100% Java
03.07.2002
Версия для печати
Выскажите свое мнение
В компании aJile Systems разработана базовая модель коммуникационного устройства, которую можно использовать в основе телефонов и PDA. Ядро устройства — однокристальный процессор aJ-100, способный без дополнительного преобразования исполнять байт-код Java. Имеются также 8 Мбайт статической оперативной памяти и 8 Мбайт флэш-памяти. В комплект поставки входит набор средств разработки. Устройство управляется Java OS и содержит ряд приложений: браузер, менеджер личной информации, клиент электронной почты, MP3-проигрыватель, средство мгновенного обмена SMS-сообщениями и игры. Имеется возможность создания защищенных разделов, позволяющих исполнять загружаемые из Internet Java-приложения без опасений за целостность системы. Базовая модель коммуникатора поддерживает стандарты GPRS и CDMA 2000. Как утверждают в aJile, реализуемая аппаратно процессором aJ-100 виртуальная машина Java работает в 10 раз быстрее большинства программных.
InfoWorld, США"
VD>В чистом виде это будет не скоро. У явы прсто нет возможностей создать высокопроизводительную ОС. В .Net появилисб задатки, но и их пока мало. Тот же GC никуда негден в масштабах ОС. К тому же нужно время. Но у MS и Sun все еще впереди.
VD>>>Так что если я не ошибаюсь, то мы еще увидим Ворд, Ёксель и SQL-сервер работающий под CLR. Интересно что ты скажещь тогда. ;) AVK>>Это да. Тут все нормально. Для последнего официально заявлено что в следущей версии хранимые процедуры будут работать в CLR.
VD>Нет. Пока все прозаичнее. Появится тлько возможность создания хранимых процедур на .Net, сам сервер пишется на сях, да и транзакт никто не отменит.
AVK>> Вот это действительно интересно, а то развели бардак полнейший. У каждого сервера своя экзекутивная часть SQL. А здесь многоплатформенность реально нужна.
VD>Гы. Для SQL2k есть апдэйт позволюющий писать SP на Яве. :) Так что...
VD>>>Ну, тут ты стал бональным плевальщиком по MS. Ворд это все же лучший продукт в соей области. AVK>>Да. Но лучше от этого он не становится.
VD>В нем есть 2-3 бага которые третируют его на протяжении 4-х лет. Интересно сколько их станет если его перепишут на C#? :)
VD>>> Если посмотреть на конкурентов, то они или критически менее фунциональны, или давально менее функциональны и в дабавок более тормозные. Думаю, если Sun всерьез бы влез на рынок офисных программ, глюки ворда исчезли бы сами собой. :) AVK>>А он пытается. Последний из могикан наверное.
VD>Вообще-то все конкуренты живы. Даже Лексикон. :)
VD>>>Многие. Но главное, что деньги есть везеде. Вот Гейтс долго расказывал, что рынок бизнес-софта его не интересуют потому как там мало денег, AVK>>Там много денег. Это он лукавил.
VD>Не думаю, что лукавил. Ошибался, возможно, но врать то ему зачем?
VD>>> а теперь вот взял и купил Навижен (серую лошадку в сфере КИС и ЕРП). AVK>>Кто такая навижн я знаю. И это отнюдь не серая лошадка. Axapta лучшая в Европе КИС. А ветку Attain они прикроют.
VD>Ну, это ты SAP. :)
VD>>>Теперь будет качать бабки и из бухгалтериий. :) AVK>>Давно пора. Аксапту кстати будут переписывать под дотнет.
VD>Ее к чертовой мотери давно нужно было полностью переписывать. В прочем как и все остальные продукты в этой области. Пусть даже и не на Нэт или Яве...
AVK>>К счастью даже у MS не получится поиметь весь софтовый рынок.
VD>А-га. Но понадкусывать может. :)
AVK>>А так все правильно. Я не о стратегии. Просто если попытаться создать продукт покрывающий все ниши то получится г. И никто этого и не делает. Разные ниши завоевываются разными продуктами.
VD>Не. Вот как раз компонентные технологии и позвляют создавать универсальные продукты. Не ноа 100% но этого и не требуется. Я уже пытался делиться мыслями в этой области, но пока видимо недоходчиво.
AVK>>Вот только абстракции все же должны опираться на особенности платформы.
VD>Нет. Они именно для того и абстаркции, чтобы на них опирались, а не наоборот.
AVK>>Если нет рефлекшена сразу большой кусок объектных моделей становится нереализуемым или реализуемым так что овчинка не стоит выделки.
VD>Рефлекшон — это часть реализации компонентного подхода. Именно он отличает COM, Яву и .Net от многих других достойных, но проигрывающих технологий и чистота его (компонентного подхода) реализаци является критически важной. Sun-у нужно пересматривать свой подход. Драть правильные идеи (не деля их на урощующие ОО и нет) и придумывать новые. Так же ему нуно наращивать скоростные характеристики Явы. Вот тогда они еще с MS повоюют. Для MS это тоже справедливо.
VD>>> А программировать на VB даже быстрее чем на Яве. AVK>>Так я о том и говорю. Кодинг на новых платформах не особенно лучше старых.
VD>Ошибаешся. Важно все. .Net тем и хорошь, что на C# и даже на VB.Net программировать еще проще чем на VB6. Иначе кому он был бы нужен?
VD>>> С ОО плохо, но для создания конечных систем это не смертельно. AVK>>Для больших систем (вроде того же КИС) — почти смертельно, особенно в плане развития.
VD>А ты знаешь на чем тот же SAP создан?
VD>>> По сути С# и VB.Net развивают достойные традиции (RAD-ости) VB 1.0, а все остальные продукты всего лишь назгребают открытую нишу. AVK>>Нет. К достойным наследникам можно отнести WinForms, отчасти ASP.NET.
VD>Я имел в виду .Net и VS.Net. Выразился плохо. Но сами языки тут тоже играют не малую роль. Без того самого компонентного подхода сделать все это было нельзя. А VB стал первым ориентированным на компоненты средством разработки. Сам язык тут конечно не причем, но концепции родились именно тогда.
VD>>> Кстати, дизайнер форм VB 1.0 это вовремя купленная на стороне идея. MS хранил эту идею несколько лет до появляения VB. AVK>>Напомнить FoxBase? Тогда еще виндюков не было, не то что VB.
VD>Напомни. Что-то я там не припомню компонентов. ;) А рисовалки интерфейсов были и до FoxPro. VB стал первой средой где появился компонентный подход.
AVK>>>>А что будет с GC? С рефлекшеном? С сериализацией? С ремоутингом? Когда начинаешь думать о деталях становится страшно. VD>>>На ничего не будут. Ну, может улучшат малость. :) AVK>>Влад, для подобных конструкций надо ручками дописывать код и обрабатывать темплейты как отдельный случай.
VD>Нет. Нужно просто ввести в MSIL или байт-код Явы абстрактные операции, ну, и тайп-инфо расширить.
AVK>> И это надо сделать во всей библиотеке.
VD>Библиотеки нужно к чертям переписывать. Все классы-списков по крайней мере. Может и линкед-лист добавят. :)
AVK>> С одной стороны неполиморфность это конечно хорошо, но с другой стороны это ведь главная прелесть ООП, и весь полиморфный код придется переписывать. Это огромная работа.
VD>Дык, на то они и монстры!
VD>>>На одной из PDC уже разавали варант CLR и .Net-компилятора который поддерживал шаблоны (только они их назвали дженерик-типы). Создатели этого чуда говорили, что им пришлось изменить MSIL и CLR, но сам дух системы остался. AVK>>Вот вот. А библиотеки они наверное почти и не правили. Добавить в язык можно.
VD>Это не входило в их задачи. Хотя могу соврать, так как сам этого чуда не видел.
AVK>>Развалится не только рефлекшн. Точно развалится например ado.net — его подсистема преобразования датасетов к модели хранилища данных.
VD>Это еще по чему? К тому же что ты под "моделью хранилища данных" понимаешь?
AVK>> В дотнете ведь даже простые типы полифорфны. А тут темплейты. Это будет особый случай вроде массивов.
VD>А никто полиморфности отменять не будет. Появятся универсальные типы, которые тоже смогут быть полиморфными. Но не только динамически, но и статически (на уровне парометризации). Очень даже может быть, что все это будет сильно отличаться от шаблнов С++-а.
VD>>>Так что же страшного принесут шаблоны? AVK>>Они могут привнести тучу глюков. Потому ни Sun ни MS особо не стремятся пока их добавлять.
VD>Гы. Они как раз от глюков избавят, перенеся многие проверки из рантайма в стадию компиляции. Ну, а создавать новый код ни MS, ни Sun не привыкать.
VD>>>Информация о типах малость расширится вместо реального типа некторые методы будут возвращать описание коворящие, что тип будет известен полько при подстановке в шаблон некоторого значения. AVK>>Представь что будет с полиморфным кодом. Темплейты придется обрабатывать как особый случай.
VD>Дык, а вчем проблема? Все в промежуточном коде, при создании типа шаблона уже не будет. Будет обычный класс. Только можно будет лучше оптимизировать код.
Здравствуйте iZEN, Вы писали:
ZEN>Тесты Java2 vs. Delphi: ZEN>http://www.beep.ru/~izen/projects/projects.html ZEN>См. "JavaTest" и "DelphiTest" ZEN>Результаты на сортировки более-менее одинаковы: кто-то в одних алгоритмах впереди, кто-то -- в других. ZEN>Результаты в вычислениях с плав.точкой просто потрясают.
К сожалению теста для Дельфи там нет (дэд-линк). Но и без этого теста я могу сказать (базируясь на наших тестах), что Дельфи будет быстрее во всех тестах (кроме строк) даже при сравнении с Ява 1.3. Если брать не вылизанные тесты, а реальные программы, то разныв в пользу Дельфи даже увеличится, потому что кодируя на Яве мало кто утруждает себя расстановкой сэйледов и других файналов.
ZEN>Swing -- просто библиотека GUI, независимая от ОС. Напишите свою -- будет ещё одна альтернатива. Кстати, есть SWT (http://www.eclipse.org/) -- системно-зависимая библиотека (как AWT), возможный конкурент Swing по компактности и быстродействию.
За ссылку спасибо, но писать свои ГУИ-ёвые библиотеки... Пускай уж это делает MS и Sun. Пока у MS это получается несравненно лучше.
AVK>>> Вобще — в настоящее время вопросы эффективности актуальны больше для коробочного софта, а для корпоративного главное чтобы можно было купить компьютер который обеспечит приемлемое быстродействие.
ZEN>Не согласен. Есть промышленные приложения реального времени. Иногда (укладывается во временные рамки) Java подходит для этого из-за устойчивости (нет утечек памяти) и стабильности.
Ява вообще не применима для реального времени, так как ее реализация GC дает разные временные характиристики на одной и той же задаче. Реалное время — это прежде всего гарантированные временные задержки.
ZEN>Он и не требует. Можно НЕ ИСПОЛЬЗОВАТЬ BeanInfo, поставляемое с Java-компонентом, а обойтись стандартным Introspector-ом.
Нельзя. Это спецификация.
ZEN>JBuilder прекрасно включает в свою палитру визуального дизайнера любые классы и можно работать с ними без напряга, но если есть BeanInfo, то будут и иконки, и спец.редакторы свойств. :))
Это как раз подтверждает мои слова. Обойтись можно, но в Sun сочли, что ради иконки можно запороть всю компонентную модель.
ZEN>Все классы -- это компоненты -- да, но только в общем смысле этого слова.
У этого слова частных смыслов я незнаю. То что Sun называет ява бобами, все остальные вот уже около 10 лет называют контролами.
ZEN>Почему же "ересь"? Просто другой подход: скрываемые поля и специфицированные (Get..(), Set..(), Is..()) методы работы с ними. Вот так и никак иначе.
Это и называется нет. Есть эмуляция, а свойств нету. Причем это всего лишь выпендреж Sun-а... Если ты о свойствах.
ZEN>BeanInfo может вернуть только ДОПОЛНИТЕЛЬНУЮ информацию.
Насколько я помню, там можно получить список методов. Может я заблуждаюсь?
VD>>Если п.3 верен, то автоматом должен быть верен и этот пункт. Так как если пасажир может выбрать два пути, то водитель должен иметь горючее на самый длинный из них.
ZEN>Нет. Нельзя сравнивать методологию MS (весь офис в одном флаконе и игрушки к системе) и Java. Это из другой жизни...:)
Это ты о пасажире или о пути? ;)
ZEN>Когда есть BeanInfo, используется BeanInfo. Когда нет BeanInfo, а срочно нужна информация о структуре класса, используется Introspector и Reflection.
Дык BeanInfo если что эмулируется на рефлекшоне, так что можно всегда через него.
ZEN>На вкус и цвет... ZEN>Меня, например, раздражает объектная модель Delphi VCL -- такой корявой структуры я больше нигде не видел.
Тебя раздржает не ОО-модель дельфи. А структура их библиотеки. Это азные вещи. Сама ОО-модель в Дельфи проста и последовательна. Хотя слишком проста и совсем недокументирована.
VD>>>>8. Компонентная модель Нэта красива, стройна и почти не противоречива.
ZEN>У вас такой вкус...:)
Я сравниваю две модели.
VD>>На существование имеет право все что существует. Вот толко мне нарвятся все красивое и гибкое.
ZEN>Опять же, ваше личное мнение о красоте не всегда совпадает с мнениями других. ZEN>Спорить о красоте, в этом случае, глупо.
А я и не отрицаю, что это мое мнение. И соглашаться никого не заставляю. ;)
VD>>Не всегда. И не везде. Раз есть BeanInfo, занчит его будут использовать. А раз будут, значит без него не обойтись. Короче, задаю вопрос еще раз... Если BeanInfo так хорошь, то почему его не использовали в Ё-бабах?
ZEN>Голословное утверждение. Приведите пример, когда срочно необходим BeanInfo, когда без него не обойтись.
Всегд где нужна информация о типах для ява боба. Иначе работать будет не все.
VD>>IComponent не подминяет технику взоимодействия с компонентом. Он добавляет (не нужные, на мой взгляд) возможности, а BeanInfo частично дублирует рефлекшен. По твоему, что, нельзя создать ситуацию когда полученная черз рефлекшен информация (я не говорю о свойсвтвах) будет отличаться от аналогичной полученной черз BeanInfo?
ZEN>Можно, но зачем это нужно? BeanInfo, в отличие от прямого reflection, обеспечивает более "человеческий" уровень понимания свойств компонента.
Свойств в Ява вообще нет. В Нэте они есть и "понимать" через решлекшон их как раз плюнуть.
VD>>Вот интересно если выдрать бины из ЯваБилдера и засунуть их в ____ (впиши сам), все из них будут работать? Да и дело в том, что не совместимы они с теми же Ё-бабами. Так как компонентная парадигма меняется. Короче, BeanInfo примочка. Ты уж или покажи зачем она нужноа, или хватит спорить.
ZEN>BeanInfo -- "примочка" для предоставления красочно-описанной информации о компоненте.
Воветую глянуть на Нэт. Там таких примочек нет, а красочность ни чуть не хуже. Правда там атрибуты есть, но файкт остается фактом.
ZEN>Нужно для разработчика, чтобы было приятно и удобно работать со свойствами компонента во время разработки приложения.
Практика показывает, что можно и без них.
VD>>Я не вострги от VCL, но с компонентной архитектурой там лучше. :-/
ZEN>Мне VCL не нравится. Но я же не кричу об этом на всю улицу.
Извени, а что ты делаешь? ;)
Не будем говорить кто это был... Но это был слоненок! :)
VD>>Да. Красный свет тоже не означает, что идти нельзя. Просто злые дятьки насували светофоров. :)
ZEN>deprecated-методы имеют в своём теле вызов "улучшенного" нового метода, так что они -- просто заглушки для использования старым кодом новых улучшенных функций.
Они устаревшие и запрещенные к использованию. Sun не гарантирует их поддржки в будущем.
VD>>>> то про поддержку старых версий. Напомню, что ты споришь с моим утверждением, что в Ява кривая компонентная модель. Не бери пример с Z, не меняй обсуждаемую тему.
ZEN>Когда это я менял тему?
См. свой спор на счет сравнения размеров JRE и .Net Runtime. В середине разговора, ты акуратно превел тему на клиентский компьютер, так и не ответив зачем на нем вообще нужна Ява.
VD>>JSP содрано с ASP. Да и не причем тут оно. КодДом самая передавая модель двунаправленной кодогенерации на сегодняшний день. В компонентной области MS тоже впереди.
ZEN>Так ли? В том же JBuilder визуальный дизайнер полностью two-way-tools, обходится без двоичных ресурсных файлов (не читая картинок). Редактируешь текст -- получаешь в визуале, ворочаешь визуал -- получаешь текст.
Ну, поставь рядом эти два средства. Разберись в обоих и поймешь, что Билдер просто детская игрушка по сравнению с VS.Net и ее CodDom.
ZEN>А где MS? "Редактируйте" res-файлы только мышкой в дизайнере!
Не понял. :???:
ZEN>А Delphi -- это вообще убожество с DFM-описаниями форм! Чуть версия не та -- заново формочку строй.
Отстал ты от жизни. У них вот уже пару версий по умолчанию текстовый формат используется, который имеет намного большую совместимость.
ZEN>Если CODEDOM -- это представление ресурсов визуальных форм в виде xml-дерева, то это реализовано в Java IDE NetBeans. Только это дерево полностью отчуждаемо от проекта.
Код дом — это не хмл. Это библиотека двунаправленной генерации кода с очень серьезными способностями к расширению. Одна из особенностей независимоть от языка. В VS.Net формы можно даже на Яве (J#) клепать.
VD>>Назови хоть один продукт который поддерживает двунаправленную генерацию кода на нескольких языках и при этом позволяет создавать встраиваемые генераторы кода для компонентов и их отдельных частей.
ZEN>Rational Rose, Together.
Это вообще не средство разработки. Это средства проектирования. Сдесь речь шала о другом. VS.Net — это компонентная среда разработки. В Розе можно спроектировать компонент, но нельзя положить его на форму и использовать.
VD>>Тем что я не лапти клепаю, а продукты которые компонентную архитектуру используют непосредственно. Мне нужна технология где я смогу сам делать контейнеры и не буду оглядываться на криворукость чужих программистов. :(
ZEN>Вы системы разработки "клепаете" что-ли? Тогда, очевидно, в некоторые моменты понадобится использовать BeanInfo. Для "обычных" приложений BeanInfo излишне.
Не, теперь я скорее буду использовать .Net.
VD>>Я уже сто раз говорил. Дублированием методов получения информации о типах и как следствие не последовательностью и кривизной компонентной модели.
ZEN>Не дублирование, но дополнение. Как вы это всё ещё не поймёте?
То что в BeanInfo больше информации я не спорю. Но там есть откровенный дубляж. Для любого кто хочет использовать компонентную модель, хочет чтобы она была просто, последовательна и непротиворечива. Дублях это точно не здорово.
VD>>Компонентная модель там не храмая. Многим нарвится и сама библиотека.
ZEN>Мне нет. Swing на порядок стройнее и продуманней.
Ну, тогда сравни результат. В свинге все компоненты — этнтри-лэвел. В VCL и WiтForms используются отлаженные и удобные контнолы из виндовс.
ZEN>InfoWorld, США"
Ну, на пресрелизы достаточно и ссылки.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте VladD2, Вы писали:
ZEN>>Swing -- просто библиотека GUI, независимая от ОС. Напишите свою -- будет ещё одна альтернатива. Кстати, есть SWT (http://www.eclipse.org/) -- системно-зависимая библиотека (как AWT), возможный конкурент Swing по компактности и быстродействию.
VD>За ссылку спасибо, но писать свои ГУИ-ёвые библиотеки... Пускай уж это делает MS и Sun. Пока у MS это получается несравненно лучше.
Не Влад, ты не въехал. Эту библиотечку пишет третий монстр — IBM.
VD>Они устаревшие и запрещенные к использованию. Sun не гарантирует их поддржки в будущем.
Здесь ты не прав. Совместимость снизу вверх он гарантирует.
VD>>>JSP содрано с ASP.
Ни в коей мере. Php и mod_perl моложе и asp и jsp. А вот asp.net явно содрана с jsp.
Влад, похоже предыдущий мой ответ глюканул и осталась одна цитата. Восстанавливать лень. Вкратце — сегодня поковырялся в доке по бинам — ты прав, BeanInfo может перекрыть информацию рефлекшена. Это криво. Но не так страшно поскольку есть интроспектор. Не лезь к бинам напрямую и тебе будет пофигу — BeanInfo там или еще что.
VD>Ну, поставь рядом эти два средства. Разберись в обоих и поймешь, что Билдер просто детская игрушка по сравнению с VS.Net и ее CodDom.
Примерно тоже есть и в современных java средах. Но там нет стандарта. Впрочем и MS до конца дело не довел.
ZEN>>А Delphi -- это вообще убожество с DFM-описаниями форм! Чуть версия не та -- заново формочку строй. VD>Отстал ты от жизни. У них вот уже пару версий по умолчанию текстовый формат используется, который имеет намного большую совместимость.
Да и раньше они без проблем конвертировались при первом открытии проекта. Проблемы были только когда пытались обратно в старой среде открыть.
VD>Код дом — это не хмл. Это библиотека двунаправленной генерации кода с очень серьезными способностями к расширению. Одна из особенностей независимоть от языка. В VS.Net формы можно даже на Яве (J#) клепать.
По моему название CodeDOM (code document object model) очень точно отражает суть. Это объектная модель кода.
VD>Это вообще не средство разработки. Это средства проектирования. Сдесь речь шала о другом. VS.Net — это компонентная среда разработки. В Розе можно спроектировать компонент, но нельзя положить его на форму и использовать.
Влад, справедливости ради — Together был пожалуй первым полномасштабным reverse engineering $ UML tool. Он и сейчас в этом плане покруче студии будет. Да и сериализация свойств из дизайнера в код появилась впервые в джаве.
ZEN>>Мне нет. Swing на порядок стройнее и продуманней. VD>Ну, тогда сравни результат. В свинге все компоненты — этнтри-лэвел. В VCL и WiтForms используются отлаженные и удобные контнолы из виндовс.
Тут про eclipse project вовремя напомнили — ну очень интересный проект. Если у ибм желание не пропадет то она будет не хуже winforms по быстродействию.
Здравствуйте AndrewVK, Вы писали:
VD>>За ссылку спасибо, но писать свои ГУИ-ёвые библиотеки... Пускай уж это делает MS и Sun. Пока у MS это получается несравненно лучше. AVK>Не Влад, ты не въехал. Эту библиотечку пишет третий монстр — IBM.
Ну, ему можно. Только ен верится, что что-нибудь путное выйдет. Они уже много начинаний делали. Но пока что зарабатывают на окучивании больших контор.
VD>>Они устаревшие и запрещенные к использованию. Sun не гарантирует их поддржки в будущем. AVK>Здесь ты не прав. Совместимость снизу вверх он гарантирует.
Это написано в описании деприкэтед. К тому же уже были прицеденты.
VD>>>>JSP содрано с ASP. AVK>Ни в коей мере. Php и mod_perl моложе и asp и jsp. А вот asp.net явно содрана с jsp.
Кроме компонентов (с трудом отличимы от инклюдов) я особо ничего нового в Asp.Net не заметил. Просто изменили язык на компилируемый. Остальное последствия. Ну, а то, что JSP содрано с ASP оно даже Sun-ом не отрицается. Первична была идея активных страниц (код и разметка в одном флаконе). Все остальное мелочи.
AVK>Влад, похоже предыдущий мой ответ глюканул и осталась одна цитата. Восстанавливать лень. Вкратце — сегодня поковырялся в доке по бинам — ты прав, BeanInfo может перекрыть информацию рефлекшена. Это криво. Но не так страшно поскольку есть интроспектор. Не лезь к бинам напрямую и тебе будет пофигу — BeanInfo там или еще что.
Может для кого и не страшно. Я уже с OLE натрахался. Вот у где непоследовательность. После этого опыта мне вся непоследовательность кажется засадой. Тут оно как... Как спроектируешь, так и работать будет. :( А у меня как раз в задачах создание контейнера, только не IDE, а интеллектуального такого.
VD>>Ну, поставь рядом эти два средства. Разберись в обоих и поймешь, что Билдер просто детская игрушка по сравнению с VS.Net и ее CodDom. AVK>Примерно тоже есть и в современных java средах. Но там нет стандарта. Впрочем и MS до конца дело не довел.
Их вообще убить моло. Создать такую гору кода, и даже ее не документировать! Ну, а на счет примерно... тоже... ты попробуй дизасемблить это дело и сравнить объемы. Я только посмотрел из дали... Глаза округлились.
Надо будет в будующем раскопать все это дело. Благо с дизасемблером и отладчиком это возможно.
VD>>Код дом — это не хмл. Это библиотека двунаправленной генерации кода с очень серьезными способностями к расширению. Одна из особенностей независимоть от языка. В VS.Net формы можно даже на Яве (J#) клепать. AVK>По моему название CodeDOM (code document object model) очень точно отражает суть. Это объектная модель кода.
Ну, видишь люди из-за схожетси с XmlDom путают ее с Xml-ем вообще. Да и "объектная модель кода" это слишком абстрактно, чтобы понять что это такое, если раньше этого дела не видел. Но по сути так оно и есть...
AVK>Влад, справедливости ради — Together был пожалуй первым полномасштабным reverse engineering $ UML tool. Он и сейчас в этом плане покруче студии будет. Да и сериализация свойств из дизайнера в код появилась впервые в джаве.
Я говорю о том, что это разные продукты. Разные подходы. Зачем сравнивать UML и VS? В VS тоже Визио входит, но речь, то я вел не о том. Я конечно понимаю, что у них есть общее разбор и генерация кода, но они разное делают. В CodDom генерация кода — это способ сериализации.
AVK>Тут про eclipse project вовремя напомнили — ну очень интересный проект. Если у ибм желание не пропадет то она будет не хуже winforms по быстродействию.
Моло верится. К тому же скорее всего проподет. Но если вдруг получится, то будет замечательно, так как конкуренция нужна однозначно!
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте VladD2, Вы писали:
VD>Ну, ему можно. Только ен верится, что что-нибудь путное выйдет. Они уже много начинаний делали. Но пока что зарабатывают на окучивании больших контор.
Ну пока выходит очень даже ничего.
VD>>>Они устаревшие и запрещенные к использованию. Sun не гарантирует их поддржки в будущем. AVK>>Здесь ты не прав. Совместимость снизу вверх он гарантирует. VD>Это написано в описании деприкэтед. К тому же уже были прицеденты.
Например?
VD>>>>>JSP содрано с ASP. AVK>>Ни в коей мере. Php и mod_perl моложе и asp и jsp. А вот asp.net явно содрана с jsp.
VD>Кроме компонентов (с трудом отличимы от инклюдов) я особо ничего нового в Asp.Net не заметил. Просто изменили язык на компилируемый. Остальное последствия.
Ты просто не разобрался — сам механизм преобразования активной страницы к исходникам класса и компиляции его на лету 1 в 1 содран с jsp. Причем содран вплоть до мелочей. Единственное отличие asp.net от jsp это web forms.
VD>Первична была идея активных страниц (код и разметка в одном флаконе). Все остальное мелочи.
Эта идея была реализована задолго до появления asp.
VD>Их вообще убить моло. Создать такую гору кода, и даже ее не документировать!
Вот я и говорю — не успевали они похоже. Будем надеяться что в следующей версии они доделают.
AVK>>Тут про eclipse project вовремя напомнили — ну очень интересный проект. Если у ибм желание не пропадет то она будет не хуже winforms по быстродействию.
VD>Моло верится.
Скачай посмотри.
VD> К тому же скорее всего проподет.
ИБМ хочет на основе коммерческий проект сделать. Eclipse это не только swt но еще и универсальная платформа для инструментальных средств. Что то вроде студии.
VD> Но если вдруг получится, то будет замечательно, так как конкуренция нужна однозначно!
Да уже почти получилось.
Здравствуйте VladD2, Вы писали:
VD>Здравствуйте iZEN, Вы писали:
ZEN>>Тесты Java2 vs. Delphi: ZEN>>http://www.beep.ru/~izen/projects/projects.html ZEN>>См. "JavaTest" и "DelphiTest" ZEN>>Результаты на сортировки более-менее одинаковы: кто-то в одних алгоритмах впереди, кто-то -- в других. ZEN>>Результаты в вычислениях с плав.точкой просто потрясают. VD>К сожалению теста для Дельфи там нет (дэд-линк). Но и без этого теста я могу сказать (базируясь на наших тестах), что Дельфи будет быстрее во всех тестах (кроме строк) даже при сравнении с Ява 1.3. Если брать не вылизанные тесты, а реальные программы, то разныв в пользу Дельфи даже увеличится, потому что кодируя на Яве мало кто утруждает себя расстановкой сэйледов и других файналов.
Ничего особого не "вылизывал". Алгоритмы, формы почти один-в-один.
Вот они:
JavaTest -- http://www.beep.ru/~izen/projects/bin/javatest.zip
DelphiTest(обновил ссылку -- работает) -- http://www.beep.ru/~izen/projects/bin/delphitest.zip
ZEN>>Swing -- просто библиотека GUI, независимая от ОС. Напишите свою -- будет ещё одна альтернатива. Кстати, есть SWT (http://www.eclipse.org/) -- системно-зависимая библиотека (как AWT), возможный конкурент Swing по компактности и быстродействию. VD>За ссылку спасибо, но писать свои ГУИ-ёвые библиотеки... Пускай уж это делает MS и Sun. Пока у MS это получается несравненно лучше.
Почему же. AWT, например, писал один человек за полтора-два месяца. :) Кстати, из-за проявленной спешки она "неудобна".
AVK>>>> Вобще — в настоящее время вопросы эффективности актуальны больше для коробочного софта, а для корпоративного главное чтобы можно было купить компьютер который обеспечит приемлемое быстродействие.
И надёжность.
ZEN>>Не согласен. Есть промышленные приложения реального времени. Иногда (укладывается во временные рамки) Java подходит для этого из-за устойчивости (нет утечек памяти) и стабильности. VD>Ява вообще не применима для реального времени, так как ее реализация GC дает разные временные характиристики на одной и той же задаче. Реалное время — это прежде всего гарантированные временные задержки.
Иногда Java больше подходит, чем C/C++...
ZEN>>Он и не требует. Можно НЕ ИСПОЛЬЗОВАТЬ BeanInfo, поставляемое с Java-компонентом, а обойтись стандартным Introspector-ом. VD>Нельзя. Это спецификация.
Можно. Никто не заставляет придерживаться спецификации до последней буквы. Есть два пути: простой(BeanInfo) и сложный(врукопашную с Introspector).
ZEN>>JBuilder прекрасно включает в свою палитру визуального дизайнера любые классы и можно работать с ними без напряга, но если есть BeanInfo, то будут и иконки, и спец.редакторы свойств. :)) VD>Это как раз подтверждает мои слова. Обойтись можно, но в Sun сочли, что ради иконки можно запороть всю компонентную модель.
А мне нравится их подход: отделение Design-time-кода от Run-time-кода.
ZEN>>Все классы -- это компоненты -- да, но только в общем смысле этого слова. VD>У этого слова частных смыслов я незнаю. То что Sun называет ява бобами, все остальные вот уже около 10 лет называют контролами. ZEN>>Почему же "ересь"? Просто другой подход: скрываемые поля и специфицированные (Get..(), Set..(), Is..()) методы работы с ними. Вот так и никак иначе. VD>Это и называется нет. Есть эмуляция, а свойств нету. Причем это всего лишь выпендреж Sun-а... Если ты о свойствах.
Да, эмуляция. А, например, в Delphi настоящие свойства лучше? Ничуть -- иногда доходит до абсурда: дублирование одних вещей разными средствами.
ZEN>>BeanInfo может вернуть только ДОПОЛНИТЕЛЬНУЮ информацию. VD>Насколько я помню, там можно получить список методов. Может я заблуждаюсь?
Да, можно. А также дополнительную информацию по ним из самого BeanInfo.
VD>>>Если п.3 верен, то автоматом должен быть верен и этот пункт. Так как если пасажир может выбрать два пути, то водитель должен иметь горючее на самый длинный из них. ZEN>>Нет. Нельзя сравнивать методологию MS (весь офис в одном флаконе и игрушки к системе) и Java. Это из другой жизни...:) VD>Это ты о пасажире или о пути? ;)
Обо всём. :)
ZEN>>Когда есть BeanInfo, используется BeanInfo. Когда нет BeanInfo, а срочно нужна информация о структуре класса, используется Introspector и Reflection. VD>Дык BeanInfo если что эмулируется на рефлекшоне, так что можно всегда через него. ZEN>>На вкус и цвет... ZEN>>Меня, например, раздражает объектная модель Delphi VCL -- такой корявой структуры я больше нигде не видел. VD>Тебя раздржает не ОО-модель дельфи. А структура их библиотеки. Это азные вещи. Сама ОО-модель в Дельфи проста и последовательна. Хотя слишком проста и совсем недокументирована.
Вспомните MVC (паттерн проектирования Model-View-Controller). Думаете, VCL придерживается его? Отнюдь.
VD>>>>>8. Компонентная модель Нэта красива, стройна и почти не противоречива. ZEN>>У вас такой вкус...:) VD>Я сравниваю две модели. VD>>>На существование имеет право все что существует. Вот толко мне нарвятся все красивое и гибкое. ZEN>>Опять же, ваше личное мнение о красоте не всегда совпадает с мнениями других. ZEN>>Спорить о красоте, в этом случае, глупо. VD>А я и не отрицаю, что это мое мнение. И соглашаться никого не заставляю. ;) VD>>>Не всегда. И не везде. Раз есть BeanInfo, занчит его будут использовать. А раз будут, значит без него не обойтись. Короче, задаю вопрос еще раз... Если BeanInfo так хорошь, то почему его не использовали в Ё-бабах?
Решили данные отделить от кода и придумали XML. В EJB данные о распространении и "инсталляции" в контейнеры засунули в deployment-descriptor(XML формата).
Контейнеры разные, у каждого свой способ инстанцирования EJB-бина и обработок транзакций.
Вот когда договорятся производители App-серверов о поддержке какого-либо унифицированного BeanInfo для EJB, тогда можно будет говорить о "настоящей бобовости" EJB-бинов.
Но зачем это нужно? Другой вопрос. Бобы с BeanInfo разработаны гораздо раньше EJB, технология BeanInfo стара(?) и непригодна(?) для быстроменяющихся условий бизнеса.
Выскажете свои "за" и "против". Как вы видите решение этой проблемы "BeanInfo для EJB"?
ZEN>>Голословное утверждение. Приведите пример, когда срочно необходим BeanInfo, когда без него не обойтись. VD>Всегд где нужна информация о типах для ява боба. Иначе работать будет не все.
???
Что "не всё"?
VD>>>IComponent не подминяет технику взоимодействия с компонентом. Он добавляет (не нужные, на мой взгляд) возможности, а BeanInfo частично дублирует рефлекшен. По твоему, что, нельзя создать ситуацию когда полученная черз рефлекшен информация (я не говорю о свойсвтвах) будет отличаться от аналогичной полученной черз BeanInfo?
Через Reflection можно получить всю информацию о run-time-"свойствах" класса.
ZEN>>Можно, но зачем это нужно? BeanInfo, в отличие от прямого reflection, обеспечивает более "человеческий" уровень понимания свойств компонента. VD>Свойств в Ява вообще нет. В Нэте они есть и "понимать" через решлекшон их как раз плюнуть.
Да, простите, свойств действительно нет (пусть будет в кавычках: "свойства").
VD>>>Вот интересно если выдрать бины из ЯваБилдера и засунуть их в ____ (впиши сам), все из них будут работать?
Да. Они же представлены в бинарном неизменном виде (*.class-файлами).
VD>>>Да и дело в том, что не совместимы они с теми же Ё-бабами.
В чём несовместимы? В том, что какой-нибудь "левый" класс, допустим наследник кнопки, не может стать EJB-бином? Зачем так извращаться? :)
В принципе, для EJB-бина можно сделать BeanInfo, но это кому надо? EJB-бины -- "интеллектуальные процедуры" по изменению и сохранению бизнес-данных.
VD>>>Так как компонентная парадигма меняется. Короче, BeanInfo примочка. Ты уж или покажи зачем она нужноа, или хватит спорить.
BeanInfo -- "примочка" для предоставления красочно-описанной информации о компоненте, неважно, каком. Надо вам -- делаете, никто не заставляет.
VD>Воветую глянуть на Нэт. Там таких примочек нет, а красочность ни чуть не хуже. Правда там атрибуты есть, но файкт остается фактом.
ZEN>>Нужно для разработчика, чтобы было приятно и удобно работать со свойствами компонента во время разработки приложения. VD>Практика показывает, что можно и без них.
???
VD>>>Я не вострги от VCL, но с компонентной архитектурой там лучше. :-/ ZEN>>Мне VCL не нравится. Но я же не кричу об этом на всю улицу. VD>Извени, а что ты делаешь? ;)
ИзвИняю. :)) VD>Не будем говорить кто это был... Но это был слоненок! :)
;) VD>>>Да. Красный свет тоже не означает, что идти нельзя. Просто злые дятьки насували светофоров. :)
ZEN>>deprecated-методы имеют в своём теле вызов "улучшенного" нового метода, так что они -- просто заглушки для использования старым кодом новых улучшенных функций. VD>Они устаревшие и запрещенные к использованию. Sun не гарантирует их поддржки в будущем.
Нет, они просто устаревшие и меют в своём теле не прежний(старый) код, а вызовы новых методов.
VD>>>>> то про поддержку старых версий. Напомню, что ты споришь с моим утверждением, что в Ява кривая компонентная модель. Не бери пример с Z, не меняй обсуждаемую тему. ZEN>>Когда это я менял тему? VD>См. свой спор на счет сравнения размеров JRE и .Net Runtime. В середине разговора, ты акуратно превел тему на клиентский компьютер, так и не ответив зачем на нем вообще нужна Ява.
То, что предлагали скачивать клиенту (.Net Redist), я сравнил с размерами и функциональностью JRE. Оказалось, что JRE в ТРИ раза (~32 Мбайт против ~11 Мбайт) весит меньше, а функциональность такая же. Кроме того, зачем .Net-клиенту нужен серверный код? Он компилить что-то будет?
VD>>>JSP содрано с ASP. Да и не причем тут оно. КодДом самая передавая модель двунаправленной кодогенерации на сегодняшний день. В компонентной области MS тоже впереди.
ZEN>>Так ли? В том же JBuilder визуальный дизайнер полностью two-way-tools, обходится без двоичных ресурсных файлов (не читая картинок). Редактируешь текст -- получаешь в визуале, ворочаешь визуал -- получаешь текст.
VD>Ну, поставь рядом эти два средства. Разберись в обоих и поймешь, что Билдер просто детская игрушка по сравнению с VS.Net и ее CodDom.
Почему игрушка? Нет лишних (.dfm, .res, .xml) файлов -- всё в чистейшем виде (only .java).
ZEN>>А где MS? "Редактируйте" res-файлы только мышкой в дизайнере! VD>Не понял. :???:
Это о версиях VS для C++.
ZEN>>А Delphi -- это вообще убожество с DFM-описаниями форм! Чуть версия не та -- заново формочку строй. VD>Отстал ты от жизни. У них вот уже пару версий по умолчанию текстовый формат используется, который имеет намного большую совместимость.
Знаю я это. Совместимость близка к нулю (из-за UNICODE в последних версиях и "новшествах" в VCL :)
ZEN>>Если CODEDOM -- это представление ресурсов визуальных форм в виде xml-дерева, то это реализовано в Java IDE NetBeans. Только это дерево полностью отчуждаемо от проекта. VD>Код дом — это не хмл. Это библиотека двунаправленной генерации кода с очень серьезными способностями к расширению. Одна из особенностей независимоть от языка. В VS.Net формы можно даже на Яве (J#) клепать.
Оно конечно. Это необходимо для поддержки нескольких языков. Я не спорю.
VD>>>Назови хоть один продукт который поддерживает двунаправленную генерацию кода на нескольких языках и при этом позволяет создавать встраиваемые генераторы кода для компонентов и их отдельных частей. ZEN>>Rational Rose, Together. VD>Это вообще не средство разработки. Это средства проектирования. Сдесь речь шала о другом. VS.Net — это компонентная среда разработки. В Розе можно спроектировать компонент, но нельзя положить его на форму и использовать.
VD>>>Тем что я не лапти клепаю, а продукты которые компонентную архитектуру используют непосредственно. Мне нужна технология где я смогу сам делать контейнеры и не буду оглядываться на криворукость чужих программистов. :( ZEN>>Вы системы разработки "клепаете" что-ли? Тогда, очевидно, в некоторые моменты понадобится использовать BeanInfo. Для "обычных" приложений BeanInfo излишне. VD>Не, теперь я скорее буду использовать .Net.
Ага. Вы хотели получить что-то похожее на OLE-контейнер для Java-приложений? Я прав?
VD>>>Я уже сто раз говорил. Дублированием методов получения информации о типах и как следствие не последовательностью и кривизной компонентной модели. ZEN>>Не дублирование, но дополнение. Как вы это всё ещё не поймёте? VD>То что в BeanInfo больше информации я не спорю. Но там есть откровенный дубляж. Для любого кто хочет использовать компонентную модель, хочет чтобы она была просто, последовательна и непротиворечива. Дублях это точно не здорово. VD>>>Компонентная модель там не храмая. Многим нарвится и сама библиотека. ZEN>>Мне нет. Swing на порядок стройнее и продуманней. VD>Ну, тогда сравни результат. В свинге все компоненты — этнтри-лэвел. В VCL и WiтForms используются отлаженные и удобные контнолы из виндовс.
Мне не нравятся интерфейсные элементы Windows. Мне что, повесится из-за этого?
В Java2 Swing можно нарисовать любой GUI, отличный от системного.
ZEN>>InfoWorld, США" VD>Ну, на пресрелизы достаточно и ссылки.
Ну так как? JavaOS жива? ;)
Живее всех живых. Просто не замечаем небольшие вещи за спинами монстров. :user:
Здравствуйте Lloyd, Вы писали:
L>P.S. Под интегрировнностью я понимаю невозможность сущетствования, того, во что интергировано, без того, что интергрированно. L>Пример -- IE интергрирован в Windows.
Я конечно не специалист по Linux, но разве Вы можете работать в Linux'е без shell (bash, etc)?
IE для Windows является примерно тем же, что и shell для Linux, к тому же MS вместе с IE распространяет свежие версии своих библиотек.
L>В этом смысле Apache вовсе не интергрирован в Linux (прекрасно существует и без него).
Windows тоже прекрасно обходиться без IIS.
С уважением,
Кирилл Филиппов
Никакую проблему нельзя решить на том же уровне, на котором она возникла
(c) Альберт Энштейн
Приветствую.
IT>В-четвётых, а давай сравнивать не в мегобайтах, а в языках программирования. Java — это "Java, Sun Java" (c) Дж. Бонд. К .NET только от MS прилагаются C#, VB, MC++, JScript, Java (!!!). Плюс уже есть с полтора десятка языков от всяких левых производителей. Поэтому, я запросто стогу писать под .NET на Java, а вот сможешь ли ты писать под Java на C#? :)))
Мне кажется, этим самым шагом "платформа для всех языков" Microsoft пытается монополизовать спектр рынка ПО для разработчиков. И свидетельством тому есть то, что язык Java уже "подгребли" под свою .NET платформу...
Если Sun выстоит и начнет антимонополистическую программу разработки мультиязыковой платформы (кстати, это сделать можно было ого-го когда) только тогда все будет хорошо, а если не выстоит, даже не хочется думать и гадать об этом...
Ничего принципиально нового в принципе нету в мультиплатформенности. Об этом задумывались еще раньше,... гораздо раньше,... уж простите меня, не могу назвать примерные даты.
С уважением, Руслан
WBR, Руслан
Re[19]: В чем счастье в С#
От:
Аноним
Дата:
17.05.04 08:42
Оценка:
Здравствуйте, Tall, Вы писали:
T>Я конечно не специалист по Linux, но разве Вы можете работать в Linux'е без shell (bash, etc)?
Не можете. Но в Windows аналогом shell является Windows Explorer (explorer.exe), а не Internet Explorer (iexplore.exe).
T>IE для Windows является примерно тем же, что и shell для Linux, к тому же MS вместе с IE распространяет свежие версии своих библиотек.
Отсюда: IE для Windows является тем же, что и Mozilla для Linux. А без Мозиллы Линукс вполне неплохо работает.
Здравствуйте, <Аноним>, Вы писали:
А>Здравствуйте, Tall, Вы писали:
T>>Я конечно не специалист по Linux, но разве Вы можете работать в Linux'е без shell (bash, etc)? А>Не можете. Но в Windows аналогом shell является Windows Explorer (explorer.exe), а не Internet Explorer (iexplore.exe).
Я бы сказал, что это 2 шелла. Проверить это легко — наберите в адресных строках iexplore и explorer C:\ и найдите 10 отличий. А>Отсюда: IE для Windows является тем же, что и Mozilla для Linux. А без Мозиллы Линукс вполне неплохо работает.
Нет. У меня, например, включен Active Desktop. Никакая мозилла этого не делает. Хотя винда сама по себе неплохо работает. А еще можно запустить в качестве шелла Far и снести експлорер. На работоспособность сервера это не повлияет.
... << RSDN@Home 1.1.4 beta 1 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, shmakov, Вы писали:
S>Может быть... я вообще на JAVA пишу -как то разницы не заметил. Так ради тренеровки навоял простенький клиент-сервер на C#. Что же... если за это будут платить буду писать и на этом добре . Хотя я уже давно понял — на чем бы не писать, какая разница, все одно while...for...if... )
Это потому, что Вы ничего кроме императивных языков не видели. Хотите нового? Смотрите Eiffiel, Haskel, ML, OCaml, Lisp, Prolog...
Да и императивные языки весьма отличаются, если подняться чуть выше банальных if, for, while.
Здравствуйте, AndrewVK, Вы писали:
AVK>Влад, мне кажется значимость шаблонов ты несколько преувеличиваешь. Ну будут они, я думаю ничего кардинально не изменится. Та же Дельфи, при отсутствии шаблонов, множественного наследования и много чего еще вполне успешно конкурирует с С++.
Здравствуйте, kuj, Вы писали:
kuj>Здравствуйте, shmakov, Вы писали:
kuj>Это потому, что Вы ничего кроме императивных языков не видели. Хотите нового? Смотрите Eiffiel, Haskel, ML, OCaml, Lisp, Prolog...
kuj>Да и императивные языки весьма отличаются, если подняться чуть выше банальных if, for, while.
Угу, посмотрите на Smalltalk, там нет конструкций языка типа if, for, while...
Здравствуйте, shmakov, Вы писали:
S>Народ -а в чем фан в C#. S>Вот написал пару приложний — все слизали с JAVA... S>Многоплатформенности нет так как нет платформ поддерживающих .NET реально. S>Я бы сказал C# = JAVA for Windows... в чем фан то....
В чем sexy? А в том, что от MS. Больше ничего особенного там нет. Особенно — это .NET.
ZEN>Читали притчу о Вавилонской башне? Почему её не могли построить, знаете? ZEN>В одной голове несколько языков -- обалдеть можно! Либо один, но отлично, либо много, но удовлетворительно. Есть что изучать до старости...
Это наверное от сложности языков. Java,C#,Delphi одного поля ягоды и переход с одного на другой дело малого времени, но есть конкуренция и соответственно языки должны развиваться и затачиваться под конкретные задачи, что явно лучше когда монополистом оказывается один язык.
Так для решения конкретной задачи может подходить один язык (Васик.Нет для позднего связывания, построение сложных полиморфных классов на Delphi с использованием метаклассов, С# имеет тоже кучу достоинств, развиваются языки для спецфиских задач, но они легко объединяются в одно целое. А специализацию в любом случае ни кто не отменял. И не нужен экскаватор где можно решить задачу лопатой.
... << RSDN@Home 1.1.0 stable >>
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, kavlad, Вы писали:
K>Здравствуйте, Serginio1, Вы писали:
S>>И не нужен экскаватор где можно решить задачу лопатой.
K>И не стоит браться за лопату, если масштабы для экскаватора
Неее без лопаты никак нельзя
... << RSDN@Home 1.1.0 stable >>
и солнце б утром не вставало, когда бы не было меня
)
Если нам не помогут, то мы тоже никого не пощадим.
. И при чем здесь заплатки? Их что — для томкета с апачей меньше надо?
Вот это похоже на настоящую аргументацию 
