Странно все как то получается. Sun сделало Java, у MS присвоить ее не получилось, пришлось делать такое же, но свое. Наняли Borland, раз уж они удачно JBuilder сделали, в котором тоже собственные классы скажем так не совсем стандартам Java соотвествуют, а более на Дельфовую иеархию смахивают. Естественно Borland парится не стал и CLR вроде как и на иеархию классов Java смахивает, и Дельфовое иногда проскальзывает, и решения старой VS проскакивают. Теперь вот спорят, кто первый изобрел "велосипед", который уже давным давно изобретен, причем не Sun, раз уж тот же Вирт еще в далекие времена Оберон наваял. Неужели у забугорного народа уши такие длинные, раз им можно лапшу в таких кол-вах вешать о "новом супер-пупер продукте". Можно подумать, что .NET умеет чего то, что не умеет Java. Отличия есть конечно, но не коренные. Основное отличие на мой взгляд - .NET более упрощен, чем Java, как в семантике языка, так и в иеархии классов. Естественно палка на 2 концах - с одной стороны на нем могут работать разработчики с более низкой квалификацией (а то как бы MS перетащил с VB6 на VB.NET народ), с другой стороны Java хоть и сложнее, но гораздо гибче в решении сложных задач. А Borland в последнее время я смотрю вообще "молодцом" - сам ничего не делает, а только IDE лепит к существующим платформам. Действительно, зачем заморачиваться, когда можно слепить аля редактор, подрубить его к уже готовой платформе и громко назвать его C# Builder. Было бы интересно узнать хотя бы 10 отличий C# Builder от VS Studio .NET. Я так подозреваю это shortcut в стиле Delphi и C Builder, собственная помощь, в которой кроме ссылок на MSDN ничего нет (поубывал бы их за помощь в JBuilder), возможно какая то часть собственных наработанных классов, перетащенных с JBuilder ... на этом собственно говоря мои мысли заканчиваются. Хотя конечно по представленной презентации Notepad в такой системе построить плевое дело :) Действительно, а что еще для жизни программисту нужно :)

P.S. Сие вышесказанное следует расценивать как юмор, надеюсь все будет понятно правильно и мы не начнем побивать рекорды по кол-ву сообщений в теме г-на 1024 :)

Я бы сказал не правильный вопрос. Для Java более правильно спросить - сколько спецификаций в Java, а в них интерфейсов :) Отвечу честно - не знаю, не считал. Знаю только, что есть все на все случаи жизни, причем спроектированные так, чтобы вся иеархия классов не оказалась жестко повязанной между собой наследованием, а разбитая по логическим моделям и соединенная между собой интерфейсами. В итоге в Java любой компонент является составным и любая его функциональная часть может спокойно заменятся собственными наработками. Наглядный пример - это модель GUI в Java и .NET. Разница очень большая. Достаточно просто сравнить. Ну а кол-во классов я не считаю показателем в лучшую сторону, если в системе слишком много классов, то это может только говорить о недостаточной продуманности иеархии базовых классов, что приведет только к проблемам. Вспомните Borland - не сильно много им пришлось VCL перепроектировать, только все дописывают, латают, всего пару раз да и то пару классов в иеархии смещали. Странно, что некоторые считают это показателем гениальности создателей VCL, типа вот такое накатали, что даже за 10 лет переделывать не пришлось. Посмотрел бы как они все "переделали" с учетом совместимости с предыдущими версиями. Такие вещи изначально должны продумываться так, чтобы потом не приходилось лепить довески. В Sun насколько я знаю интерфейсы и спецификации для Java целыми командами разработчиков обсуждаются, перед тем, как будет принято решение об их вводе в эксплуатацию. А так как мне уже пришлось уже работать в .NET с GUI и CGI+, то могу сказать, что лучше бы они все заново переделали, пока не поздно. Сильно на простой довесок напоминает, а не продуманную иеархию визуальных компонент и обьектов графики.

Ню ню. Если у Antonz единственный аргумент, что Java - отстой, потому что он на ней программировал 2 года (даже не уточнив на какой и что он на ней делал), а теперь перешел на .NET, потому что это MS и cool, то это действительно весомый аргумент :) Вообще то как только человек начинает вспоминать про дерьмо у меня возникают серьезные подозрения по поводу его знания предмета, который он охаивает. Я могу себе позволить критиковать Delphi, так как работаю на нем с 95 года и имею в за спиной кучу крупных проектов на ней, порядка 100 собственных классов и компонент и долгое копание и борьбу с глюками как в самой VCL, так и компонент сторонних производителей (тот же DevExpress Quantum Grid или FastReport). На .NET привелось писать классы, компоненты, визуал и работать с графикой. Поэтому и сравнил с Java, потому как в ней тем же занимался в свое время. Вообще то самое сложное в освоении продукта я так понимаю это принятие его философии, особенно если она от MS/Borland идей очень отличается, и это не только Java касается, а того же например Sybase Power Builder, который настолько сильно отличается от других инструментов построения клиентов БД, что те же дельфийцы при первом знакомстве с ним матятся и орут что на таком "г" работать не будут. Только вот если в своей голове пересмотреть концепцию построения GUI приложений с привычного взгляда на идеи, реализованные в PB, то оказывается, что все программируется на нем просто, быстро и довольно таки мощно, во всяком случае клиентов БД после него я бы на Delphi, .NET или Java уже не рискнул бы делать, это просто была бы потеря времени и гемморой по сравнению с тем что предлагает Power Builder :)

Угу. Я при первом взгяде на него понял, что самый простой способ познакомиться с PB - это напрочь забыть, как я привык на Delphi программы писать. Все равно философию программирования сложно изменять - на первых порах все равно пытался решать проблемы привычными Дельфовыми методами. Потом разобрался, в потрохах покопался, поделал тестовых проектов, собственные наработки в библиотечку сформировались и оказалось, что это действительно очень крутой инструмент для построения клиентов БД - фактически сейчас на PB, опираясь на его стандартные решения и собственные наработки я могу ваять удобный и продвинутый интерфейс клиента с необходимым уровнем бизнес-логики, фактически пользуясь только мышью. Причем что еще интересно, что сам язык PB и его модель ООП коренно отличаются от стандартных подходов ООП, применяемых в таких языках как C#, Java или Delphi, как итог - писать на PB что то кроме клиента будет просто не реально (даже свой визуальный компонент не разработаешь), а вот разработать собственную иеархию бизнес-логики, моделей просмотра данных, приделать к стандартным контролам нужное поведение - как раз все более удобно и более логично, чем в настоящих ООП языках. Ну в принципе так и должно быть - универсальное средство всегда более сложно для решения специализированных задач, а узкоспециализированные средства никогда не станут универсальными, потому как не надо их использовать не по назначению.

А я наоборот именно из за этого и поменял средство разработки, что на PB быстрее, легче и беспроблемнее, чем в Delphi, рисовать клиентов БД для крупных проектов. Потому как я в основном занимаюсь проектировкой и разработкой БД и являюсь руководителем проекта, мне выгоднее, чтобы клиентская часть в процессе разработки не тормозила весь проект. Во всяком случае в PB достаточно разработать толковую иеархию обьектов бизнес-логики и интерфейса программы и можно смело сажать кодеров на рисование мышой форм и отчетов с помощью DataWindow на основе полученных запросов, да и то - по умолчанию DataWindow будут правильно генерится за счет расширенной метаструктуры БД, поддерживаемой PB и описанной DBA, останется только фактически мышой обьекты красиво по форме растаскать, ненужные убрать и дополнительный код по бизнес-логике ввода документа написать. Как итог - клиентская часть пишется довольно быстро, сильно навороченные кодеры не нужны, в случае чего они легко заменяемы и их код изначально содержит мало ошибок и легко контролируется, раз уж его почти нет. Для написания крупных проектов, особенно "безнадежных", согласитесь самое оно :)

К сожалению у нас в России у нас выбор инструмента проводится по принципу "Что знаю и нравится, то и беру". Например я уверен, что для разработки интернет приложений .NET с его ASP.NET самое выгодное решение. В области распределенных приложений и кроссплатформенных решений Java имеет очень серьезные наработки, а для создания GUI приложений под Windows Delphi очень и очень удобна. Но заметьте, сколько сейчас народу на том же C# (Java, Delphi, etc) пытаются лепить GUI клиентов БД, в котором это естественно можно делать, необходимые компоненты есть, но при сравнении с тем же PB реально этот процесс гораздо более трудоемок, так как изначально C# является не специализированным в этом области языком, и уж явно не может внутри кода оперировать понятиями и конструкциями SQL (фича PB), а делает это как и любой уважающий себя ООП язык только на уровне компонент, что при построении бизнес-логики клиентской части приводит к дополнительному коду и размыванию самой бизнес-логики. Производители инструментария кстати этому очень сильно способствуют - тот же Borland мечется из стороны в сторону - сначала Delphi обьявили инструментом для разработки клиентской части БД, потом заявили, что теперь на Delphi можно писать CGI приложения под Web, потом решили ее сделать кроссплатформенной, теперь вот последняя фича - аля C# Builder и Delphi.NET. Итог плачевный - каждая из заявленных фич до конца не доработанна и глюкава, с учетом громких заявлений многие разработчики, вместо того, чтобы перейти на более специализированный и подходящий продукт, остаются на Delphi. В принципе у .NET та же самая проблема - GUI больше напоминает довесок к ASP.NET, чем решение. Какой был смысл MS убивать VB, вместо того, чтобы его просто доработать и более специализировать на построение клиентской части БД, с учетом того, что все равно VBA жив, а MS поставило программистов VB перед проблемой усложнения языка ? Фактически без кое каких мелочей смело можно написать VB.NET = C# , что перечеркнуло все преимущества VB, как легкого интерпретируемого языка. Что мне нравится в Java, что Sun пытается развивать его эволюционно не с точки зрения маркетинга, а целесообразности, основываясь на пожеланиях и опыте работы разработчиков. Что мне нравится в Sybase (Power Builder, Power Designer и SQL ASA), так это то, что их продукты всегда в эволюционном развитии и даже не только новая версия продукта, но и простой пак являются шагом по усовершенствованию и доработке продукта (недаром частенько с паком валяется и помощь, содержащую в себе описания дополнительно функционала продукта, включенного в сервис-пак). Да и форумы отладки у них очень замечательно работают - любая обнаруженная ошибка публикуется в форум, выясняется сообществом и командой разработчиков ее условия возникновения и последствия, в течении недели-двух исправляется, тестируется, выкладывается пак, далее если в форумах по выложенному паку эта ошибка не упоминается, снимается как исправленная ошибка. А я вот сколько не помню Borland Delphi и BDE, так ошибки там уже больше 5 лет крутяться и в каждой новой версии в помощи обязательно присутствует трогательное заверение разработчиков, что уж в следующей версии эта ошибка будет исправлена. Вот и получается, что в Sun ошибок и просчетов просто нет, так как любая разработка проходит тщательный контроль и планирование, в продуктах Sybase ошибки периодически возникают, так как их продукты находятся в непрерывном эволюционном процессе, но моментально исправляются с учетом отлаженного механизма работы в реальном времени с пользователями, в Borland не исправляются никогда, а только накапливаются, в MS исправляются только тогда, когда достигают некой критической массы, причем иногда путем полной смены курса (думаю все согласны, что со всеми глюками старой VS, да заодно и COM Microsoft покончила раз и навсегда).

P.S. Вот такое вот длинное сообщение после n-ного кол-ва пива :) Надеюсь не сильно утомил своими взглядами на производителей инструментария ПО :)

Интересно, а вообще зачем на яве делался такой богатый набор различных элементов форм?
Дык изначально Java была создана под аплеты, так что графика и GUI там очень на высоте. У меня сейчас друг на Java делает графический дизайнер для моделирования обуви. Старая версия проекта была сделана на C Builder, но за годы эксплуатации и поддержки проекта стало очевидно, что его надо переписывать с нуля и уводить с C Builder. Сначала было решено писать проект на C#, но после тестовых испытаний CLR выявились 2 вещи - иеархия графических классов не продуманна, векторная графика GDI+ страшно тормознутая. На Java же наоборот скорость и продуманность графических обьектов оказались на высоте, что и не удивительно, так как изначально разработчики Java это дело обтачивали, давя на то, что в апплетах под инет будет активно использоваться графика и GUI. Кстати виртуальная машина Java на автопилоте подключает Direct3D или OpenGL, если таковые существуют на текущей ОС, чтобы ускорить и оптимизировать всю графику.


Интересно, очень долго пытался найти в JBuilder'e события TextBox TextChange так и не нашел. Я имею ввиду, если пользоваться мышкой. Интересно, а оно вообще в Java есть.

Угу - есть. Только все по другому. Изначально вся иеархия компонентов подчиняется схеме "модель-документ-контроллер". Очень удобно - все компоненты связаны между собой интерфейсами, хочется чтобы например у меня во всех компонентах, поддерживающих скролирование пространства был свой ScrollBox достаточно раз написать и везде можно использовать. Все данные компоненты получает через интерфейс "документ". в итоге мне все равно откуда в том же ListBox или Grid будут данные возвращаться - по интерфейсу "документ" подключаем необходимый компонент и все работает. Причем изначально любой компонент, работающий с данными (edit-ы, listbox, grid, checkbox и т.д.) поддерживает интерфейс документ и значит будет прекрасно работать с нашей моделью доступа к данным, которая может кстати оказаться не только dataset, но и деревом и чем угодно :) Особенно это круто выглядит с компонентами сторонних производителей - мы покупаем у них необходимый функционал и спокойно его через интерфейсы расширяем, не прибегая к наследованию и фактически доработке компонента, как это пришлось бы сделать в том же Delphi. Ну а через контроллер визуальные компоненты себя фактически рисуют. Поэтому там в Swing так элементарно можно рисовать скины приложения и централизованно управлять информацией, которую используют при отрисовке все визуальные компоненты приложения. Кстати аплеты подвигли Sun встроить еще одну классную фичу - LayoutManager. Фактически любой визуальных компонент, служащий контейнером, имеет кучу своих схем правил размещения контролов на нем, ну конечно с возможностью дописывания собственных схем, хотя там уже по моему ничего придумать нельзя нового - все есть. При правильном использовании LayoutManager можно добиться того, что контролсы всегда будут правильно и пропорционально располагаться, вне зависимости от размеров контейнера. По идее в C# этого тоже можно добиться через Anchor и Dock, но не всего, что умеет LayoutManager.

P.S. И никогда не судите о Java по Borland JBuilder. IDE супер-глюкава, код среда генерит отвратный, половина спецификаций визуальных компонент не поддерживается, собственные компоненты от Borland противоречат всем концепциям Java. Так что JBuilder не самый лучший способ познакомиться с Java. Не удивлюсь, если Borland такое же и в C# Builder натворит.

Маveric:
В догонку отвечу:
Я уверен, как руководитель, ты будешь всерьез рассматривать только те инструменты что знаешь ты. И правильно.
Это правильно и не правильно. С одной стороны руководитель проекта действительно должен знать инструмент, на котором пишется проект. С другой стороны какой смысл поручать человеку руководство крупным проектом, который явно должен организовываться по схеме клиент-сервер, если он знает только Access ? Что такой человек напишет ? И если например я имею 12 летний стаж работы и работал на многих инструментах, то это не означает, что выбирать инструмент я буду на основании того, что мне больше нравиться. Мне например Sybase SQL ASA очень и очень нравится, но под проект, в котором будут идти обработки гигантского кол-ва информации я его брать не буду, так как под такие обьемы он не заточен. Если же мне предложат проект, к которому явно не подходит не один из знакомых мне инструментов, то правильней будет от него отказаться, сэкономив деньги заказчику и нервы себе. За рубежом не знаю как, но у нас таким принципам точно не следуют, как итог иногда приходится с нуля переписывать чужие проекты только потому, что при их разработке использованы инструменты не по назначению, хромала постановка проекта или же он был написан не кач-но, по принципу "сели и поехали, колеса в дороге приделаем".