Ответ на »сообщение 350« (Evgeny)
___________________________

Интересный вывод: приводить цифры по жабомобилкам и убеждать всех в неимоверной крутизне продукта на сайте дельфийской тематики - это не комплекс неполноценности, а привести статистику по количеству пользователей - комплекс :)
А в декабре 2000 (у нас в это время вовсю был проект жаба/с++/корба), когда начиналась тема, оказывается о жабе "слышали далеко не все".
Хорошая мина при плохой игре.

Вот еще статистика по динамике доли мелкомягких ОСей на серверах (по лицензиям):
2001 - 50.5%
2002 - 55.1%
2004(1 квартал) - 69.4%

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

P.S. Пришлось недавно посидеть за WebSphere Studio 5. Цензурных слов у меня нет: борландовские и микрософтовские IDE после этого кажутся чем-то прекрасным и далеким.
Яркий пример того, что описывал Спольски в своей статье про интерфейсы, на каждом шагу прорамма говорит пользователю: "Не работает, потому что ты тупой".

Ответ на »сообщение 349« (Сергей Тарасов)
___________________________
Ну, зачем уж, так реагировать, с таким комплексом неполноценности.
Когда начиналась эта тема, о Джаве слышали далеко не все. И ей предрекали, если не скорую смерть, то по крайней мере очень узкую область применения.
Джава жива и имеет неплохие перспективы.
Дельфи очень славная система, но 950к и 2.5м все-таки о чем-то говорят.
К сожалению мне не пришлось на ней активно работать, я изучал ее только для собственного удовольствия, кстати как и Джаву. Поэтому я в какой-то мере нейтральный наблюдатель.

Прочитал этот топик с большим интересом. Очень поучительно.

С уважением Евгений.

Ответ на »сообщение 348« (iZEN)
___________________________

Пользователей в мире на октябрь 2003
Delphi = ~ 950k
C++ = ~ 4.5 millions
Java = ~2.5 millions

Не густо за 8 лет при таких-то начальных наполеоновских планах.

Полмиллиарда мобилок и смарткарт у людей с Явой - это уже показатель.

Китайцы написали свой офис на Java. Чем им не понравился OpenOffice?

Снимки с Марса "проходят" через Яву. Странно, почему не используется Си?

Ответ на »сообщение 160« (Казанцев Алексей)
___________________________

Для iZEN:
"Что ж, сетка может оставаться той же, но дождёмся аппаратного обеспечения персоналок (RISC-процессор 2ГГц, RAM 512Мб, SystemBus 1ГГц) -- может для Java наступит время..."

Ждите. А когда дождетесь и производительность Ваших Java-приложений сравнится с производительностью нынешних скомпилированных приложений, может поймете на что тратятся драгоценные мега/гигагерцы и мегабайты.

Вот и дождались: http://www.fcenter.ru/articles.shtml?processors/9368
AMD Athlon 64/Socket939.
Частота от 2.2ГГц и выше.
Шина HyperTransport работает на частотах до 1 ГГц.
;)

отношение? мне java уже давно нравилась, а прикупил памяти, так еще больше нравится стала... (-:

/**Lamer:
Уже есть Linux-часы наручные.
*/

Хорошая новость(http://www.compulenta.ru/news/2001/10/12/20491/):
12.10.2001, 03:59
"11 октября компании IBM и Citizen объявили о том, что ими была завершена разработка образца часов-компьютера под управлением Linux «WatchPad 1.5».

Часы «WatchPad 1.5» оснащены 32-разрядным процессором с тактовой частотой 74 МГц, оперативной памятью объемом 8 Мбайт, flash ROM памятью емкостью 16 Мбайт, черно-белым жидкокристаллическим QVGA дисплеем (320х240), поддерживают технологию беспроводной передачи голоса и данных Bluetooth, а также стандарт на инфракрасную передачу данных и вывод на печать IrDA 1.2. Кроме того, устройство снабжено встроенным динамиком, микрофоном, тепловым сенсором, сенсором ускорения и виброзвонком. Размеры часов составляют 46х65х16 миллиметров, а их вес – 43 грамма.

Сроки появления «WatchPad 1.5» на рынке все еще неизвестны, однако с большой долей уверенности можно сказать о том, что в марте 2002 года образец будет проходить заключительные тестирования."

/**

iZEN :

Сравниваю я два инструмента и думаю:
библиотеки Java (<strong>JFC+JDBC</strong>) гораздо лучше проработаны в технологическом плане

*/
1)Уважаемый iZEN, я не спорю , что технологически JFC+JDBC может быть лучше чем VCL,MFC,CLX,etc,etc,etc...

Но речь шла о <strong>быстродействии</strong> !

И здесь как раз все упирается именно в JFC+JDBC vs VCL+ADO - т.е. в их сочетании.

Мне кажется , что пара JFC+JDBC vs VCL+ODBC была бы приблизительно равной по скорости (скорость работы JVM учитывать не будем).

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

любая библиотека в <strong>широкотиражном</strong> продукте
будет расчитана на очень широкий круг задач со всеми вытекающими отсюда минусами и проблемами. В противном случае  резко сужается круг задач ввиду специализации => падает количество продаж => либо фирма - производитель взвинчивает цену на продукт в N раз, либо теряет кучу у.е.


Если JFC+JDBC Вам подошло - классно, Вам повезло. А если бы не повезло ?

В любом случае жаба,дельфи,Вижуал Це - не важно - не нравятся стандартные библиотеки - пишем сами, ищем freeware/commercial библиотеки либо платим $$$ сторонним разработчикам за заточку инструмента под ваши цели.


P.S. Вы можете позвонить в Borland и попросить решить проблему с быстродейтсвием VCL+ADO - они решат, даже быстро.
Только стоить это Вам будет ...

/**
MegaWolt:
<..>так что это не джава такая хорошая<...>
*/

Сравниваю я два инструмента и думаю:
библиотеки Java (JFC+JDBC) гораздо лучше проработаны в технологическом плане, чем VCL+ADO, особенно это касается доступа к БД. Особенно меня смущают "промежуточные" компоненты VCL TDataSource, многие свойсва которых есть в других компонентах. Да и вообще, компоненты доступа к БД разные, а свойсва повторяются во многих из них. Какой из них главнее?
Странно, но в JDBC отсутствует такой класс как TDataSet в Delphi. Конечно, на него чем-то похож Java-класс ResultSet, но идеологии работы разные.
TDataSet инкапсулирует всё содержание набора данных (файл, таблица) независимо от подключения, а также методы работы с записями. ResultSet -- класс, инкапсулирующий "живые" данные, полученные в результате SQL-запроса, тоже со своими методами навигации и определения типа. Но есть несколько типов ResultSet: возвращающий набор записей, возвращающий целое число, возвращающий множественный набор результатов.
В Java не надо городить огород из компонентов, чтобы получить набор данных из БД на простой SQL-запрос -- отсюда: компактные программы с чёткой логикой работы. Borland в JBuilder, как всегда постаралась и инкапсулировала классы JDBC в JBCL-компоненты -- DB JavaBeans от Borland более изящное решение чем в Delphi.

АДО - самая тормозная вещь и того, что придумал мелкософт для доступа к данным.

АДО, RDO , JET - это все программные интерфейсы для доступа к данным через ODBC с разным количеством промежуточных звеньев между пользователем и ODBC API.

Если надо повысить быстродействи для работы с MSSQL Server
то лучше всего использовать SQL-DMO или ODBC API.

так что это не джава такая хорошая - это АDO такое голимое

P.S. Тормознутость ADO мелкософт оправдывает простым интерфейсом доступа к данным