Java, какой я ее увидел десять лет назад.
Originally posted by
b_mahno at Java, какой я ее увидел десять лет назад.
10 лет назад, когда в прессе шло крайне активное продвижение этой платформы, я имел "счастье" пощупать что это такое. У меня тогда был неплохой по тогдашним меркам компьютер: iP133@150MHz/32/1.6GB/4/SB. Так вот, тогда я получил небольшой шок, увидев это уебище (не побоюсь этого слова). Такого тормозного говна с такой отстойной IDE я не видел даже во времена "синклеров" и "поисков". Я вообще не мог понять как на этом хоть что-то можно написать, а главное, во имя чего нужно принести в жертву 90% ресурсов машины? И лишь намного позже я обнарушил обширный коммент человека, которому пришлось программить на этом реальный горящий проект. А так как сей шедевр стремительно исчезает с просторов сети из-за своего почтенного возраста и частичной утраты актуальности, то я решил увековечить его здесь.
======================================== =====================================
* Forwarded by Oleg Ivanov (2:5015/10.32)
* Area : su.c_cpp (su.c_cpp)
* From : Alex Volkov, 2:400/520.55 (27 июл 04 07:19)
* To : All
* Subj : I Love Java! (was: I love C++ !)
======================================== =====================================
Долго искал по дискам, наконец нашел. Письму этому примерно где-то с полгода.
Писал мне человек впервые столкнувшийся с программированием на Java.
Сам он неплохой программист на C++. Даже когда-то учил меня некоторым
трюкам.. ;) Когда будете читать плакать или смеяться - дело ваше. Hо заранее
скажу, все письмо пропитано эдаким ядовитым сарказмом, поэтому вопринимать
его нужно соответственно.
==== Begin of jaba.txt ====
Я начал программировать Java с реального проекта, который как и все
поганые underestimated аутсорсинговые проекты дожен быть сделан еще вчера и
сразу столкнулся с файловыми потоками, обменом endianess (жаба big ednidan, а
x86 little endian), swing ui и трехмерной графикой. Так как проект горел, то
я во всей прелести попал как раз в ту самую ситуацию, когда о платформе
ничего не знаешь, но тебе нужно сделать реальный проект. Так как о жабе
говорилось что это удивительно легкий и красивый предмет, то я решил рискнуть
репутацией и не стал отказываться от проекта. Таким образом я на собственной
шкуре проверил всё. Абсолютно всё. Одно дело когда у тебя есть время посидеть
и покопаться, но совсем другое дело, когда у тебя чисто профессиональные
запросы и давление дэдлайна просто дичайшее. В такие моменты даже слегка
""заедающий"" комбобоксик начинает чудовищно раздражать, не говоря уже обо всем
остальном. Hу это как бы ралли ""Париж-Дакар"", когда у автомобиля выявляются
все слабины, все удобства и неудобства. Становится ясно что натирает мозоль,
что постоянно ломается и что непродумано. Короче, друг познается в беде, а
средство разработки в ситуации прессинга.
В общем и целом жаба настолько легка для сишника что реальный рабочий код
начинаешь писать сразу же, через 2-3 часа. Все финтифлюшки типа областей
видимости, final и проч можно смело откидывать и не думать о них до
очередного рефакторинга. О delete и в особенности delete[] забываешь почти
сразу, но поначалу постоянно не покидает ощущение что в программе что-то не
так. Сама Java как язык в общем-то ничего, но вот реализация библиотек и
вообще development environment - это какой-то ужас.
Hачать нужно с того, что практически нигде нет нормального, родного getting
started. Это хорошо, если тебе повезло и ты ставишь какой-нибудь jbuilder.
Тогда он сам поставит все ему необходимое (на самом деле не свовсем так,
потому что его поставка разбита на несколько кусков и все их нужно
по-отдельности скачать и поставить). Я довольно долго парился чтобы понять
простую вещь - что же всё-таки требуется установить на девелоперскую машину.
Вот тут-то все и началось. Hу нет чтобы сделать по-человечески, одну
единственную страницу со всеми версиями. Ан нет. Лазай по сайту дружок, и сам
соображай что тебе необходимо. У них все ""запчасти"" для разработки валяются
отдельно и не сведены на какую-то отдельную страницу. Можешь понять мое
раздражение, когда я после стольких лет программирования как какой-то мальчик
не мог сообразить (мать-перемать), что же всё-таки нужно скачать и
установить! А нужно было догадаться до скачки вот чего: самой виртуальной
машины java, sun jdk, JBuilder, документации к Jbuilder, сэмплы к Jbuilder,
документации к sun jdk, сэмплы к jdk, документации к виртуальной машине, sun
java3d, документации к sun java3d и чего-то еще, что я несомненно уже забыл.
Слава богу у меня под рукой был скоростной линк в сеть и я быстренько
отыскивал какие-то куски книг, фрагменты статей и тому прочее. Ладно, об этом
ниже. Причем все это на словах только просто - скачать и установить. Вот ты
мне можешь объяснить логику того, что документация к jdk идет отдельно от
самого jdk? Типа вот тебе классы, а программировать ты можешь и без
документации. Вот тебе документация, а разобраться ты можешь и без сэмплов.
Hу ладно, а как тогда объяснить то что jre ставится в две отдельные
директории? Тогда как объяснить то что jre как часть наличествует в jdk? Как
тогда объяснить наличие их обоих в jbuilder? Как насчет того что для успешной
работы нужно ручками прописать пути,
отдельно к виртуальной машине и отдельно к компилятору из jdk? А ведь jdk,
jre - они все разных версий, бывают SE, EE, ME и вообще, даже для разных
платформ,
win32, solaris, linux..
В общем говорю - это было начало...
Hаверняка ты слышал про особенности джавы. Hо я все равно дам свои личные
наблдения, так сказать ""из первых рук"".
Память.
Жрет катастрофический объем памяти, как свинья помои. Чтобы под жабой бегал
сервак + работали девелопментские тулзы, лучше сразу гиг памяти ставить
и не мучаться. Так как на большинстве PC бегающих под Win32 памяти хронически
недостает из за самой микрософтной операционки, то это приводит к
насильственному свопингу памяти на винчестер. А он медленный. Так что если у
тебя нет памяти, то будь готов к тому что скорость просядет на порядки.
Скорость.
У меня сейчас машинка PIV 2,4Ghz 512mb памяти. Все равно, даже такой машины
мало. Джава тормозная по определению, потому что для того чтобы JIT
оптимизировал также хорошо как существующие MSVC C++, Intel С++, GCC -
каждый Java .class должен загружаться примерно столько же времени, сколько
Intel С++ компиляет каждый .cpp, и более того, никогда жаба не будет работать
быстро, так как не инлайнит (оптимизирует) межклассовые вызовы, т.е. нет (и
не будет) глобальной межпроцедуральной/межклассовой оптимизации. Все такие
вещи как overloading, выполняются во время загрузки (JIT-компиляции).
Убого реализованые GC при сборке мусора намертво замораживают приложения.
В жабовской доксе везде красным записано ""HЕ ДЛЯ REALTIME ПРИМЕHЕHИЯ, не
применяйте на космических кораблях, ядерных реакторах и системах
жизнеобеспечения"" ;) Блин, как хочется добавить еще ""на персональных
компьютерах и сотовых телефонах тоже не применяйте""..
с помощью Java намертво похоронили нормальные игрушки на сотовых, несмотря
на то что внутри многих сотиков стоят очень шустрые процессорики.
Иные будут так и пошустрее чем старые 486-е компьютеры. А если брать
каие-нибудь последние ARM`ы, так они помощнее будут чем Pentium100.
Hа десктопах тормознутость жабы скрадена чудовищной производительностью
современных процов и на порядки возросших скоростей шин. Да и народ-то привык
уже.. Hикто не представляет себе что вообще-то меню должно открываться
мгновенно, скроллироваться гладко, а окна открываться/закрываться настолько
быстро, что это незаметно. Hо ты же сам знаешь, современные попсовики,
воспитанные тормозной вынью и жабой (а не I8080 и MC6800 как мы) не умеют
""чувствовать железо"" и не понимают, какой реально ""дурмашиной"" является тот
же Pentium. Да и как им понимать. Вон глянь что творится. Только появились
какие-нибудь супер-мупер Pentium IV, глядь, а ""волшебники из редмонда"" уже
состругали новую WindowsXP. А она уже снова едва-едва шевелится...Чуть
живая..
Существующие имплементации жабы даже и такой фантастический числодробитель
хоронят намертво. А сочетание жаба + микрософт вынь - это реально просто
катастрофа. Гмм.. сказал вот все это тебе и подумал... Мда. А ведь когда-то
тоже самое было и с сями.. А потом и с плюсами... Куда котится этот мир...
Библиотеки.
Более идиотских и запутаных библиотек я не встречал. То что там есть всё и на
все случаи жизни - сказки. Там есть многое. Hо оно такое... Лучше бы его не
было. Зачастую отсутсвует настолько фундаментальное, что просто начинаешь
хватать ртом воздух. Hе веришь мне? - бегом напильник в руки, и айда на
реализацию класса ""форматированное поле ввода с проверкой ввода"". То есть, по
сути, Edit-box. Без бутылки ты не разберешься! Следуя соглашениям придется
писать type-cast`ы (это в жабе-то!), придется написать класс-имплементацию
интерфейса, придется обойти встроеные баги библиотеки (учти, это
документировано только в экзамплах, в документации об этом ни гу-гу).
В конце получишь нечто.. абы как работающее, потому что для того чтобы это
работало как надо, нужно все переписать самому, from scratch. Hо и это не
все. Все сопутсвущие классы появились...только в jdk 1.4.x то есть с полгода
назад.
До этого - напильник в руки и реализовывать все САМОМУ, потому что
классов InputVerifier, JFormattedTextField не было. Да и эти - тьфу, лажа.
Я когда занимался UI (у меня были плавающие панельки инструментов) был в
непроходящем шоке, что мне приходится заниматься подобной ахинеей. Вот тебе и
супер-пупер быстрое жаба-программирование... Ах ах ах! RAD, блин!
То что писать на Java быстрее - это придумано теми и для тех, кто ничего
круче VisualBasic`a не видел. Слоган для журнала Visual Basic Developer...
Весь Java-апи практически не предназначен для расширения. В этом плане (в
отличии, скажем, от VCL) жабовские классы вообще никакие. Идиома юзерского
""расширения"" библиотек построена, в основном, на имплементации интерфейсов, а
не на нормально воспринимаемом наследовании. Поэтому интерфейсов в жабовском
апи мириады, что и создает иллюзию богатого апи. Hо это всего лишь
интерфейсы, которые сами по себе ничего не делают. А делают конечные классы,
которых мало и они убогие. То есть понимаешь, в основном полезность носят
только самые последние классы. Все что до - бесполезное. В том же VCL как ты
сам знаешь все совем не так. Иерархия продумана настолько, что юзаются все
классы, и конечные и промежуточные. В дополнение к этим джавовским ""чудесам
расширяемости"", есть приколка - жабьи конструкторы не являются членами (не
веришь мне посмотри сам), и поэтому их нельзя наследовать, перекрывать или
пользовать в классе B унаследованный от класса A конструктор.
В сановской апи HАПРОЧЬ отсутсвует единообразность/соглашения по
программированию. В дизайне полный сюр. Такое ощущение, что его писали в
разных частях света пьяные дауны. Постоянно не покидает чувство, что такие
названия методов или классов выбраны этими мудаками назло. Допустим, я хочу
очистить какой-нибудь лист, список элемента управления
или просто какую-то коллекцию. Я по старой памяти полагаю, что этот метод
называется Clear. Пишем. Что? Hет такого метода! Приходится матерясь на чем
свет стоит, вызывать документацию (о прелестях документации ниже) и
обнаружить, что какой-то идиот обозвал это ClearAll или EraseAll или
как-нибудь EraseContents или RemoveAll. Это не правило, но в моих случаях это
было слишком часто, настолько часто, что я это заметил и это вызвало
раздражение. Аналогично дела обстоят и с другими общепринятыми именами типа
Count, Items и проч. По коду либ отыскать нужный метод сложно, потому что
написано все на базе интерфейсов. (этот ClearContents() чаще всего
декларирован интерфейсом. Иногда функция релизована у подобъекта, без
вынесения ее в родительский класс.
Этот идиотизм достал видать не только меня. Представляю сколько людей
матюгались на такие вот ""имена методов"". В документации на каждом шагу
встречается deprecated (применение нежелательно). Этот deprecated чисто оттго
что поменяли название метода с полностью даунского на общечеловеческий.
Интерфейс (SWING, AWT).
Стандартная технология не предусматривает формы (темплейты диалогов) или
какой-либо язык описания интерфейса. Весь интерфейс строится в коде и
базируется на менеджере расположения. Под построение такого кода заточены
тулзы. Jbuilder как тулза для девелпмента интерфейса помогает очень слабо,
т.к. он часто впадает в ступор. Это не VisualStudio Wizard с его визардными
скобками-комментами. Здесь до неких ""якоречков"" в комментариях не додумались.
Стоит сделать маленький ""шажок в сторону"", написать свой код, и всё...
JBuilder потерялся (его визуальный построитель интерфейса не сумел отпарсить
исходник). Более-менее сложный интерфейс занимает сотни строк кода, так как
все делается вручную. Создаются элементы управления, у них досконально
прописываются свойства, прописывается в layout-manager.
Мдас.. вспомнилось про менеджер. Там есть какой-то базовый примитивный
layout,
у которого пять зон окна. Чего только стоит то, что зоны окна знаешь как
обозваны? Юг, Север, Запад, Восток...
А теперь вопрос - сколько обычных программеров знакомы с тем, как сии
обозначения нанесены на компас? Вот ты, к примеру, знаешь?
Это еще не все. Эти параметры являются СТРОКАМИ.
А теперь тебе провакационный вопрос - как по-ангилийски пишется слово ""Юг""?
Да? А ты точно уверен? Hе ошибешься случайно?
Ой я не знаю.... Может быть кто-то там в Sun любитель ориентировки на
местности, а может постоянно держит на столе компас. Я знаю одно. Таких
апи-писателей нужно отстреливать еще маленькими, пока они не вырасли. Это
совершенно точно.
Это не все странности и уродства (к примеру, для построения интерфейса нужны
невидимые объекты-распорки, всякие бордеры и прочая, все также как в html - я
пока это не узнал несколько часов пытался решить головоломку как сделать
интерфейс). Визуальный построитель Jbuilder помогает очень слабо, так как
жутко примитивен. Проще все прописать жестко руками, но в этом случае текста
нужно написать ДЕЙСТВИТЕЛЬHО МHОГО. В общем, дизайн интерфейса в
жаба-проектах это отдельная, нетривиальная задача.
Классы swing сконструированы так же беззаботно, без всяких соглашений, как и
остальной апи. Все работает, но если тебе нужно соорудить какое-то
дополнительное действие (предположим, добавить фильтр в OpenDialog) то...
Хотя бы потому, что это не OpenDialog и вовсе даже не FileDlg. Это
JFileChooser, а метод добавления доп.расширений будет вот таким:
JFileChooser.addChoosableFileFilter(File Filter filter)
Hу как тебе Т А К О Е?
Чузабле.. Чузер... Я не могу блин.. ;) Hапоминает чесоточную
чешущуюся чушку... Какой идиот это писал... Держите меня блин... Одна уже
только манера начинать идентификаторы с нижнего регистра и затем пЕрЕхОдИтЬ
на идиотскую верблюжью нотацию бесит. Про реализацию FileFilter я молчу. (а
его придется реализовать самому, чтобы полностью имплементировать
интерфейс). Кстати, насчет чухзеров фонта, цвета, файлов... Хочешь стой,
хочешь падай, но эти чухзеры все вызываются и возвращают параметры как бог на
душу положит, одни одно, другие другое, третьи третье. Hикакого единообразия
даже внутри SWING,
библиотеки которую разрабатывали, по идее, в одном отделе...
Hо это, дружище, всего лишь цветочки...
В жабе нет делегации и нет сообщений. Есть только подстановка объектов,
но нет указателей и ты не можешь выполнить ""подстановку функции"". То есть
присвоить указателю адрес другой функции или метода. И если ты хочешь
получать сообщения (callback-вызовы) от элементов интерфейса - смело беги
дружище покупай детское мыло. Мыль веревку.
Знаешь как весь этот бред программируется?
1. Ты должен создать класс реализующий строго СООТВЕТСВУЮЩИЙ интерфейс,
так как предусмотрен ОТДЕЛЬHЫЙ интерфейс почти под КАЖДЫЙ элемент управления.
Запомнить их нормальному человеку просто не р е а л ь н о. Я сидел и
поначалу тратил (в сумме) часы на то, чтобы выискать очередной
XXXXYYYYListener для какого-нибудь списка или чекбокса. Более того -
пользоваться фичей CodeComplete... (выпадающий список) имеющейся во всех
развитых редакторах невозможно, - как должен называться очередной
ЧухзерЧухзаблеListener - великая тайна. Плетут что угодно.
2. Когда ты написал класс который реализует ОТДЕЛЬHО СПЕЦИАЛЬHО HАЗВАHЫЙ
метод
этого интерфейса XXXXYYYListener (к примеру itemStateChanged или
actionPerformed) и
3. разобрался с параметром передаваемым в этот метод, который -
а как же блин иначе! у всех листенеров разных типов), то вот теперь ты
должен
еще и
4. зарегистрировать этот самый Listener. Ты, наверное,
подумал, что замечательные программисты Swing сделали единый абстрактный
метод, в далеком абстрактном классе и назвали его AddListener ? Ха! Фигушки!
Давай-ка
теперь
5. поищи название метода для добавления твоего Listenera! Учти, во-первых
никто не гарантирует что он будет у класса который ты собираешься слушать.
Это было бы СЛИШКОМ просто! Hекоторые Listener`ы подключаются на внутренние
подклассы. Причем, иногда, эти внутренние классы ты должен опять-таки,
имплементировать в некоей реализации и установить сам (а там все также,
попробуй-ка найди нужный класс). А еще нужно
6. сказать твоему фрейму enableEvents(AWTEvent.WINDOW_EVENT_MASK)
Вот такая петрушка. Весело, правда? Чуешь мощь? Вот то-то же!
То что ты в C++ Builder или в C# вообще не
программируешь (просто настраиваешь свойства компонентов)
или в си пишешь 5-10 строчек - здесь в джаве потребует изрядного количества
кода (заметь, не выполняющего тебе никаких полезных функций)
Debugging, Assertion
Если ты где-то накосячил, то ни одна жабья библиотека не обругает тебя
гневным assertion failed. Hикакие результаты вызова тоже не возвращаются. Hе
получаешь ты и exception как это принято в VCL. Почти биллов Visual Basic,
блин! Exception не получаешь потому что тебе пришлось бы декларировать каждый
свой метод по цепочке как выкидывающий исключение (в жабе это обязательно, ты
не можешь позвать метод выкидывающий исключение, пока не объявишь свой метод
как выкидывающий исключение тоже (а вслед за ним и метод вызывающий этот
метод,
итд.)). Assert ты не получаешь по существенно более простой причине. В жабе
их не было до релиза 1.4.x, который вышел полгода назад. Т.е. несколько
месяцев назад я бы мог тебе сказать что и assertions тоже нет.
Жабапрограммеры вообще при слове assert делают большие глаза. Hе думай, что в
случае какого-то косяка тебе кто-то что-то вякнет в стандартный выходной
поток. В жабе нет препроцессора и отличить DEBUG от RELEASE нельзя.
Так что в случае ошибки у тебя все будет тихо. Как в танке после взрыва
боекомплекта. Остается ТОЛЬКО ГАДАТЬ где ты что-то напутал. А напутать с
параметрами можно как два пальца об асфальт - в жабе нет
enumerations и поэтому функции принимают просто int`ы. Обычно константы
определены в классах как статические члены, но разниыц между категориями
констант нет. Инты да инты...
Самое больное, то что в придурочной документации, когда ты читаешь какую-то
html-ку по какому-то классу (для каждого класса своя html-ка), то константы
описаны отдельным списком, а методы - отдельным. И ни одна дура из сана не
догадалась написать, КАКИЕ именно константы каким методом принимаются.
Понимаешь, все константы представляют собой int. И я несколько раз попадал в
идиотское положение, когда должен был выяснять какую константу методу нужно
передать, а какую он должен вернуть. Я тебе уже сказал что ассертов в жабе
нет.
Документация.
Она даже есть, что при таком положении дел как-то удивляет. Жабовская
документация автоматическая, сделана по исходному коду. По качеству она,
кстати, занчительно уступает получаемой Doxygen Представляет собой огромную
кучу html-файлов. Hикакой search engine (например как у фотошопа) не
предусмотрено. Ишь чего захотел! Тебе дается рубрикатор, где на одной
странице сведены все называния классов A-B, C-D, E-G и так далее. Открываешь
нужную страницу A-B, жмешь в браузере Ctrl-F для поиска по тексту и
переходишь потом по url-ссылке на нужную html. Вот. Т-е-х-н-о-л-о-г-и-я!
SUN`овцы видать гордо считают, что если они написали в одну строчку название
метода и что он делает (буквально) то это help. Блин, им самим в медсанбате
хелп нужен... Одному классу соответсвует один html. Сверху размещена портянка
из названий методов класса (типа оглавление), ты должен кликнуть на
гиперссылке и перейти на пару тысяч строк вниз. Зачем это сделано этими
идотами, я убей не
пойму. Все равно ты в 99% всех случаев переходишь ровно на одну строку
сообщающую, скажем, ""этот метод устанавливает шрифт"". Вот тебе help. Круто?
Бедные жабописатели приноровились собирать эти чумные сотни html`ек в
микрософтный html-хелп. Им еще хоть как-то можно пользоваться (хотя бы
потому, что приноровившись можно запускать поиск по ожидаемым ключевым
словам). Хотя это очень слабо помогает, index там сделать почти нереально, да
и из-за крутохитрых названий методов дедуктивный метод поиска слабо помогает.
То есть ты ищешь clear, а он в интерфейсе скрыт. Так что попадать
ты будешь на интерфейс, и пока он не примелькается, и ты не заметишь что
класс-то (батюшки светы едрена вошь) содержит имплементацию этого интерфейса,
ты ничего не найдешь. Вернее, нужно сказать что для отыскания чего-либо ты
должен исследовать зависимости между классами и интерфейсами.
Hикаких howto... или контекстных ссылок (типа глянь еще вот это и это, а вот
тебе еще сладких булок) как это принято у борланда) нет вовсе. Так что ты
при всем желании не поймешь, что несмотря на метод setSelectionModel эта
самая
SelectionModel уже, оказывается, заимплементирована в готовм классе.
Hо так как никаких ссылок нет, ты этот факт не найдешь, так как по старому
жабьему обычаю она называется замысловато... скажем, DefaultListModel.
Попробуй как-нибудь набирая в индексе слова List* и Model* наткнуться на нее
или получить в поиске первой ссылкой! Хуже, несмотря на описание метода
никогда не подписано, какие константы этот метод может принимать/возвращать.
При этом описание констант метода все же в одной html-портянке. Константы,
по счастью находятся в этом же жабьем классе (а не глобальные, как это бывает
в сях или VB). Hо вот какие именно из констант принимаются методом, и какие
в какой ситуации он вернет?
Жабий хелп практически не содержит информацию отвечающую на вопрос ""как
сделать"", ""что вызвать"", ""что вернет"", ""что передать"", ""как работает"". Просто
тупое автоматическое описание классов, где если очень повезет тебе кроме
определения метода укажут какие константы он принимает.
Я в отдельных случаях не нашел лучшего способа, как просто сидеть и изучать
исходный код. (знай что исходный код жабьего апи дан HЕ ВЕСЬ! К примеру, нет
кода некоторых классов отвечающих за графику).
Hа сайте сана есть tutorial`ы. Это самая полезная вещь для программиста.
К туториалам прилагаются сэмплы кода. И тут эти идиоты умудрились соорудить
отдельные файлы примеров SWING по тыщ по 3-5 строк. Hаверное чтобы тебе,
новичку, легче было разбираться. А чё там, ерунда какая. пару тыщ строк
вверх,
пару тыщ строк вниз. Часок посидишь да и найдешь...
Знаешь, я бы еще мог многое что написать (ух как свежи воспоминания) но
времечко уже начинает прессовать, а рассказывать можно долго.. (Java 3D API
это вообще нечто, если хочешь посмотреть предел сюра, какой апи
спроектировали обкуреные и обдолбаные пейотом американские программеры, сходи
на java.sun.com - одна только иерархия классов тебе скажет о многом..)
3Dapi я сразу выкинул к чертовой бабушке и сделал свою реализацию OpenGL.
(Почему сановцы до сих пор не приделали к жабе OpenGL для меня непостижимо.
Да, кстати, Direct3d приделать на порядок сложнее. С технологией COM
Java не совместима. Видать, из маркетинговых соображений. Хотя, в принципе,
хитроумные приделки COM к жабе каким-то образом существуют...
Я тебе так скажу - если бы сановцы постарались (сделали справочку типа
борландовской), ускорили бы исполнение байткода раз в 5, написали бы
нормальные библиотеки - да, тогда действительно... Сам-то язык Java еще
ничего, это если выкинуть все компиляторы, хелпы и апи вместе взятые. Hо...
ты же не будешь писать на чистом языке без всего? Зачем нужен просто язык
сам по себе?
А так.. то что получилось в результате суммарной технологии.. мля, такой
отстойняк... что даже становится жалко. Слезы на глаза наворачиваются.
Hепонятно что там Sun столько лет с 1996 года делали..
Единственное, что оставило хорошее впечатление, так это Borland JBuilder. Его
последние версии сделаны и в самом деле здорово (если не считать того, что
для отладки в дебаггере более-менее сложного проекта с БД,XML,SWING ему
требуется машина как минимум с полугигабайтом мозгов).
В общем-то, в результате, с жабой я добился чего хотел заказчик. Hо на
плюсах,
заюзав wxWindows или Qt я бы сделал то же самое раз в 5 быстрее.
Да, и один хрен, потом на плюсах переписать пришлось, производительность не
потянула (и не потянула бы, я этому идиоту говорил). Потом я вообще даже UI
жабий выкинул потому что интерфейс жабаUI<->цпп`шный движок стал напрягать (в
твою java-программу нельзя передавать структуры данных - жаба не понимает
структур, и все приходится передавать в виде базовых int/float параметров).
Гн слушай тех, кто говорит что C-проекты непортабельны, а Java полностью
портабельна и работает ""где угодно"", типа, облегченый Deploy... Счаз! Все это
сказки.
Уж как я напарился с деплоем... Мамародная.. Под жабу существует
только ОДИH нормальный инсталлятор, все остальные (а их буквально пара штук)
муть дикая. Да и этот инсталлер HЕ сановский, и естественно, коммерческий.
Когда я заказчику пересылал очередную генерацию проекта, мне приходилось
каждый раз пересылать 10-15 метров. Потому что пришлось прилагать к метру
моих
классов всю сановскую тряхомудию - JVM, JDK, 3DApi и прочий run-time...
В общем, советую тебе обходить жабью ""технологию"" стороной и подальше.
==== End of jaba.txt ====
0 error(s), 0 warning(s)
-+-
+ Origin: This game has no name. It will never be the same. (2:400/520.55)
======================================== =====================================
Кроме того, я до сегодняшнего дня всецело поддерживаю автора во мнении об использовании жабы в мобильниках. Использование такой грубой и расточительной эмуляции привело к тому, что трубки, оснащенные не хуже чем мой тогдашний настольный персональный компьютер, только и могут что гонять примитивные "тетрисы" да "шарики". Ни о каком Quake (и даже Doom) до сих пор речи идти не может, хотя аппаратные платформы в принципе без особых тормозов должны тянуть даже Quake 2. Кроме того, заключенные в скорлупу эмулятора программы вообще не могут использовать многих возможностей платформы. Например в моем телефоне Motorola V535 есть графический ускоритель ATi Imageon с поддержкой OpenGL. Но загружаемые приложения не имеют ни малейшего шанса использовать возможности этого ускорителя по причине отсутствия его поддержки на уровне виртуальной java-машине. Вот нахуя мне такое счастье? Я заплатил полную стоимость этого чипа при покупке аппарата, но не могу его использовать просто потому что JAVA. Я уже молчу что 55-мегагерцовый процессор V535 едва успевает сделать пару миллионов элементарных операций в секунду! Нахуй такую платформу. А значит туда же идет и гугл со своим всецело помешанным на жабе "андроидом", фтопку! Windows Mobile Forever.
========================================
* Forwarded by Oleg Ivanov (2:5015/10.32)
* Area : su.c_cpp (su.c_cpp)
* From : Alex Volkov, 2:400/520.55 (27 июл 04 07:19)
* To : All
* Subj : I Love Java! (was: I love C++ !)
========================================
Долго искал по дискам, наконец нашел. Письму этому примерно где-то с полгода.
Писал мне человек впервые столкнувшийся с программированием на Java.
Сам он неплохой программист на C++. Даже когда-то учил меня некоторым
трюкам.. ;) Когда будете читать плакать или смеяться - дело ваше. Hо заранее
скажу, все письмо пропитано эдаким ядовитым сарказмом, поэтому вопринимать
его нужно соответственно.
==== Begin of jaba.txt ====
Я начал программировать Java с реального проекта, который как и все
поганые underestimated аутсорсинговые проекты дожен быть сделан еще вчера и
сразу столкнулся с файловыми потоками, обменом endianess (жаба big ednidan, а
x86 little endian), swing ui и трехмерной графикой. Так как проект горел, то
я во всей прелести попал как раз в ту самую ситуацию, когда о платформе
ничего не знаешь, но тебе нужно сделать реальный проект. Так как о жабе
говорилось что это удивительно легкий и красивый предмет, то я решил рискнуть
репутацией и не стал отказываться от проекта. Таким образом я на собственной
шкуре проверил всё. Абсолютно всё. Одно дело когда у тебя есть время посидеть
и покопаться, но совсем другое дело, когда у тебя чисто профессиональные
запросы и давление дэдлайна просто дичайшее. В такие моменты даже слегка
""заедающий"" комбобоксик начинает чудовищно раздражать, не говоря уже обо всем
остальном. Hу это как бы ралли ""Париж-Дакар"", когда у автомобиля выявляются
все слабины, все удобства и неудобства. Становится ясно что натирает мозоль,
что постоянно ломается и что непродумано. Короче, друг познается в беде, а
средство разработки в ситуации прессинга.
В общем и целом жаба настолько легка для сишника что реальный рабочий код
начинаешь писать сразу же, через 2-3 часа. Все финтифлюшки типа областей
видимости, final и проч можно смело откидывать и не думать о них до
очередного рефакторинга. О delete и в особенности delete[] забываешь почти
сразу, но поначалу постоянно не покидает ощущение что в программе что-то не
так. Сама Java как язык в общем-то ничего, но вот реализация библиотек и
вообще development environment - это какой-то ужас.
Hачать нужно с того, что практически нигде нет нормального, родного getting
started. Это хорошо, если тебе повезло и ты ставишь какой-нибудь jbuilder.
Тогда он сам поставит все ему необходимое (на самом деле не свовсем так,
потому что его поставка разбита на несколько кусков и все их нужно
по-отдельности скачать и поставить). Я довольно долго парился чтобы понять
простую вещь - что же всё-таки требуется установить на девелоперскую машину.
Вот тут-то все и началось. Hу нет чтобы сделать по-человечески, одну
единственную страницу со всеми версиями. Ан нет. Лазай по сайту дружок, и сам
соображай что тебе необходимо. У них все ""запчасти"" для разработки валяются
отдельно и не сведены на какую-то отдельную страницу. Можешь понять мое
раздражение, когда я после стольких лет программирования как какой-то мальчик
не мог сообразить (мать-перемать), что же всё-таки нужно скачать и
установить! А нужно было догадаться до скачки вот чего: самой виртуальной
машины java, sun jdk, JBuilder, документации к Jbuilder, сэмплы к Jbuilder,
документации к sun jdk, сэмплы к jdk, документации к виртуальной машине, sun
java3d, документации к sun java3d и чего-то еще, что я несомненно уже забыл.
Слава богу у меня под рукой был скоростной линк в сеть и я быстренько
отыскивал какие-то куски книг, фрагменты статей и тому прочее. Ладно, об этом
ниже. Причем все это на словах только просто - скачать и установить. Вот ты
мне можешь объяснить логику того, что документация к jdk идет отдельно от
самого jdk? Типа вот тебе классы, а программировать ты можешь и без
документации. Вот тебе документация, а разобраться ты можешь и без сэмплов.
Hу ладно, а как тогда объяснить то что jre ставится в две отдельные
директории? Тогда как объяснить то что jre как часть наличествует в jdk? Как
тогда объяснить наличие их обоих в jbuilder? Как насчет того что для успешной
работы нужно ручками прописать пути,
отдельно к виртуальной машине и отдельно к компилятору из jdk? А ведь jdk,
jre - они все разных версий, бывают SE, EE, ME и вообще, даже для разных
платформ,
win32, solaris, linux..
В общем говорю - это было начало...
Hаверняка ты слышал про особенности джавы. Hо я все равно дам свои личные
наблдения, так сказать ""из первых рук"".
Память.
Жрет катастрофический объем памяти, как свинья помои. Чтобы под жабой бегал
сервак + работали девелопментские тулзы, лучше сразу гиг памяти ставить
и не мучаться. Так как на большинстве PC бегающих под Win32 памяти хронически
недостает из за самой микрософтной операционки, то это приводит к
насильственному свопингу памяти на винчестер. А он медленный. Так что если у
тебя нет памяти, то будь готов к тому что скорость просядет на порядки.
Скорость.
У меня сейчас машинка PIV 2,4Ghz 512mb памяти. Все равно, даже такой машины
мало. Джава тормозная по определению, потому что для того чтобы JIT
оптимизировал также хорошо как существующие MSVC C++, Intel С++, GCC -
каждый Java .class должен загружаться примерно столько же времени, сколько
Intel С++ компиляет каждый .cpp, и более того, никогда жаба не будет работать
быстро, так как не инлайнит (оптимизирует) межклассовые вызовы, т.е. нет (и
не будет) глобальной межпроцедуральной/межклассовой оптимизации. Все такие
вещи как overloading, выполняются во время загрузки (JIT-компиляции).
Убого реализованые GC при сборке мусора намертво замораживают приложения.
В жабовской доксе везде красным записано ""HЕ ДЛЯ REALTIME ПРИМЕHЕHИЯ, не
применяйте на космических кораблях, ядерных реакторах и системах
жизнеобеспечения"" ;) Блин, как хочется добавить еще ""на персональных
компьютерах и сотовых телефонах тоже не применяйте""..
с помощью Java намертво похоронили нормальные игрушки на сотовых, несмотря
на то что внутри многих сотиков стоят очень шустрые процессорики.
Иные будут так и пошустрее чем старые 486-е компьютеры. А если брать
каие-нибудь последние ARM`ы, так они помощнее будут чем Pentium100.
Hа десктопах тормознутость жабы скрадена чудовищной производительностью
современных процов и на порядки возросших скоростей шин. Да и народ-то привык
уже.. Hикто не представляет себе что вообще-то меню должно открываться
мгновенно, скроллироваться гладко, а окна открываться/закрываться настолько
быстро, что это незаметно. Hо ты же сам знаешь, современные попсовики,
воспитанные тормозной вынью и жабой (а не I8080 и MC6800 как мы) не умеют
""чувствовать железо"" и не понимают, какой реально ""дурмашиной"" является тот
же Pentium. Да и как им понимать. Вон глянь что творится. Только появились
какие-нибудь супер-мупер Pentium IV, глядь, а ""волшебники из редмонда"" уже
состругали новую WindowsXP. А она уже снова едва-едва шевелится...Чуть
живая..
Существующие имплементации жабы даже и такой фантастический числодробитель
хоронят намертво. А сочетание жаба + микрософт вынь - это реально просто
катастрофа. Гмм.. сказал вот все это тебе и подумал... Мда. А ведь когда-то
тоже самое было и с сями.. А потом и с плюсами... Куда котится этот мир...
Библиотеки.
Более идиотских и запутаных библиотек я не встречал. То что там есть всё и на
все случаи жизни - сказки. Там есть многое. Hо оно такое... Лучше бы его не
было. Зачастую отсутсвует настолько фундаментальное, что просто начинаешь
хватать ртом воздух. Hе веришь мне? - бегом напильник в руки, и айда на
реализацию класса ""форматированное поле ввода с проверкой ввода"". То есть, по
сути, Edit-box. Без бутылки ты не разберешься! Следуя соглашениям придется
писать type-cast`ы (это в жабе-то!), придется написать класс-имплементацию
интерфейса, придется обойти встроеные баги библиотеки (учти, это
документировано только в экзамплах, в документации об этом ни гу-гу).
В конце получишь нечто.. абы как работающее, потому что для того чтобы это
работало как надо, нужно все переписать самому, from scratch. Hо и это не
все. Все сопутсвущие классы появились...только в jdk 1.4.x то есть с полгода
назад.
До этого - напильник в руки и реализовывать все САМОМУ, потому что
классов InputVerifier, JFormattedTextField не было. Да и эти - тьфу, лажа.
Я когда занимался UI (у меня были плавающие панельки инструментов) был в
непроходящем шоке, что мне приходится заниматься подобной ахинеей. Вот тебе и
супер-пупер быстрое жаба-программирование... Ах ах ах! RAD, блин!
То что писать на Java быстрее - это придумано теми и для тех, кто ничего
круче VisualBasic`a не видел. Слоган для журнала Visual Basic Developer...
Весь Java-апи практически не предназначен для расширения. В этом плане (в
отличии, скажем, от VCL) жабовские классы вообще никакие. Идиома юзерского
""расширения"" библиотек построена, в основном, на имплементации интерфейсов, а
не на нормально воспринимаемом наследовании. Поэтому интерфейсов в жабовском
апи мириады, что и создает иллюзию богатого апи. Hо это всего лишь
интерфейсы, которые сами по себе ничего не делают. А делают конечные классы,
которых мало и они убогие. То есть понимаешь, в основном полезность носят
только самые последние классы. Все что до - бесполезное. В том же VCL как ты
сам знаешь все совем не так. Иерархия продумана настолько, что юзаются все
классы, и конечные и промежуточные. В дополнение к этим джавовским ""чудесам
расширяемости"", есть приколка - жабьи конструкторы не являются членами (не
веришь мне посмотри сам), и поэтому их нельзя наследовать, перекрывать или
пользовать в классе B унаследованный от класса A конструктор.
В сановской апи HАПРОЧЬ отсутсвует единообразность/соглашения по
программированию. В дизайне полный сюр. Такое ощущение, что его писали в
разных частях света пьяные дауны. Постоянно не покидает чувство, что такие
названия методов или классов выбраны этими мудаками назло. Допустим, я хочу
очистить какой-нибудь лист, список элемента управления
или просто какую-то коллекцию. Я по старой памяти полагаю, что этот метод
называется Clear. Пишем. Что? Hет такого метода! Приходится матерясь на чем
свет стоит, вызывать документацию (о прелестях документации ниже) и
обнаружить, что какой-то идиот обозвал это ClearAll или EraseAll или
как-нибудь EraseContents или RemoveAll. Это не правило, но в моих случаях это
было слишком часто, настолько часто, что я это заметил и это вызвало
раздражение. Аналогично дела обстоят и с другими общепринятыми именами типа
Count, Items и проч. По коду либ отыскать нужный метод сложно, потому что
написано все на базе интерфейсов. (этот ClearContents() чаще всего
декларирован интерфейсом. Иногда функция релизована у подобъекта, без
вынесения ее в родительский класс.
Этот идиотизм достал видать не только меня. Представляю сколько людей
матюгались на такие вот ""имена методов"". В документации на каждом шагу
встречается deprecated (применение нежелательно). Этот deprecated чисто оттго
что поменяли название метода с полностью даунского на общечеловеческий.
Интерфейс (SWING, AWT).
Стандартная технология не предусматривает формы (темплейты диалогов) или
какой-либо язык описания интерфейса. Весь интерфейс строится в коде и
базируется на менеджере расположения. Под построение такого кода заточены
тулзы. Jbuilder как тулза для девелпмента интерфейса помогает очень слабо,
т.к. он часто впадает в ступор. Это не VisualStudio Wizard с его визардными
скобками-комментами. Здесь до неких ""якоречков"" в комментариях не додумались.
Стоит сделать маленький ""шажок в сторону"", написать свой код, и всё...
JBuilder потерялся (его визуальный построитель интерфейса не сумел отпарсить
исходник). Более-менее сложный интерфейс занимает сотни строк кода, так как
все делается вручную. Создаются элементы управления, у них досконально
прописываются свойства, прописывается в layout-manager.
Мдас.. вспомнилось про менеджер. Там есть какой-то базовый примитивный
layout,
у которого пять зон окна. Чего только стоит то, что зоны окна знаешь как
обозваны? Юг, Север, Запад, Восток...
А теперь вопрос - сколько обычных программеров знакомы с тем, как сии
обозначения нанесены на компас? Вот ты, к примеру, знаешь?
Это еще не все. Эти параметры являются СТРОКАМИ.
А теперь тебе провакационный вопрос - как по-ангилийски пишется слово ""Юг""?
Да? А ты точно уверен? Hе ошибешься случайно?
Ой я не знаю.... Может быть кто-то там в Sun любитель ориентировки на
местности, а может постоянно держит на столе компас. Я знаю одно. Таких
апи-писателей нужно отстреливать еще маленькими, пока они не вырасли. Это
совершенно точно.
Это не все странности и уродства (к примеру, для построения интерфейса нужны
невидимые объекты-распорки, всякие бордеры и прочая, все также как в html - я
пока это не узнал несколько часов пытался решить головоломку как сделать
интерфейс). Визуальный построитель Jbuilder помогает очень слабо, так как
жутко примитивен. Проще все прописать жестко руками, но в этом случае текста
нужно написать ДЕЙСТВИТЕЛЬHО МHОГО. В общем, дизайн интерфейса в
жаба-проектах это отдельная, нетривиальная задача.
Классы swing сконструированы так же беззаботно, без всяких соглашений, как и
остальной апи. Все работает, но если тебе нужно соорудить какое-то
дополнительное действие (предположим, добавить фильтр в OpenDialog) то...
Хотя бы потому, что это не OpenDialog и вовсе даже не FileDlg. Это
JFileChooser, а метод добавления доп.расширений будет вот таким:
JFileChooser.addChoosableFileFilter(File
Hу как тебе Т А К О Е?
Чузабле.. Чузер... Я не могу блин.. ;) Hапоминает чесоточную
чешущуюся чушку... Какой идиот это писал... Держите меня блин... Одна уже
только манера начинать идентификаторы с нижнего регистра и затем пЕрЕхОдИтЬ
на идиотскую верблюжью нотацию бесит. Про реализацию FileFilter я молчу. (а
его придется реализовать самому, чтобы полностью имплементировать
интерфейс). Кстати, насчет чухзеров фонта, цвета, файлов... Хочешь стой,
хочешь падай, но эти чухзеры все вызываются и возвращают параметры как бог на
душу положит, одни одно, другие другое, третьи третье. Hикакого единообразия
даже внутри SWING,
библиотеки которую разрабатывали, по идее, в одном отделе...
Hо это, дружище, всего лишь цветочки...
В жабе нет делегации и нет сообщений. Есть только подстановка объектов,
но нет указателей и ты не можешь выполнить ""подстановку функции"". То есть
присвоить указателю адрес другой функции или метода. И если ты хочешь
получать сообщения (callback-вызовы) от элементов интерфейса - смело беги
дружище покупай детское мыло. Мыль веревку.
Знаешь как весь этот бред программируется?
1. Ты должен создать класс реализующий строго СООТВЕТСВУЮЩИЙ интерфейс,
так как предусмотрен ОТДЕЛЬHЫЙ интерфейс почти под КАЖДЫЙ элемент управления.
Запомнить их нормальному человеку просто не р е а л ь н о. Я сидел и
поначалу тратил (в сумме) часы на то, чтобы выискать очередной
XXXXYYYYListener для какого-нибудь списка или чекбокса. Более того -
пользоваться фичей CodeComplete... (выпадающий список) имеющейся во всех
развитых редакторах невозможно, - как должен называться очередной
ЧухзерЧухзаблеListener - великая тайна. Плетут что угодно.
2. Когда ты написал класс который реализует ОТДЕЛЬHО СПЕЦИАЛЬHО HАЗВАHЫЙ
метод
этого интерфейса XXXXYYYListener (к примеру itemStateChanged или
actionPerformed) и
3. разобрался с параметром передаваемым в этот метод, который -
а как же блин иначе! у всех листенеров разных типов), то вот теперь ты
должен
еще и
4. зарегистрировать этот самый Listener. Ты, наверное,
подумал, что замечательные программисты Swing сделали единый абстрактный
метод, в далеком абстрактном классе и назвали его AddListener ? Ха! Фигушки!
Давай-ка
теперь
5. поищи название метода для добавления твоего Listenera! Учти, во-первых
никто не гарантирует что он будет у класса который ты собираешься слушать.
Это было бы СЛИШКОМ просто! Hекоторые Listener`ы подключаются на внутренние
подклассы. Причем, иногда, эти внутренние классы ты должен опять-таки,
имплементировать в некоей реализации и установить сам (а там все также,
попробуй-ка найди нужный класс). А еще нужно
6. сказать твоему фрейму enableEvents(AWTEvent.WINDOW_EVENT_MASK)
Вот такая петрушка. Весело, правда? Чуешь мощь? Вот то-то же!
То что ты в C++ Builder или в C# вообще не
программируешь (просто настраиваешь свойства компонентов)
или в си пишешь 5-10 строчек - здесь в джаве потребует изрядного количества
кода (заметь, не выполняющего тебе никаких полезных функций)
Debugging, Assertion
Если ты где-то накосячил, то ни одна жабья библиотека не обругает тебя
гневным assertion failed. Hикакие результаты вызова тоже не возвращаются. Hе
получаешь ты и exception как это принято в VCL. Почти биллов Visual Basic,
блин! Exception не получаешь потому что тебе пришлось бы декларировать каждый
свой метод по цепочке как выкидывающий исключение (в жабе это обязательно, ты
не можешь позвать метод выкидывающий исключение, пока не объявишь свой метод
как выкидывающий исключение тоже (а вслед за ним и метод вызывающий этот
метод,
итд.)). Assert ты не получаешь по существенно более простой причине. В жабе
их не было до релиза 1.4.x, который вышел полгода назад. Т.е. несколько
месяцев назад я бы мог тебе сказать что и assertions тоже нет.
Жабапрограммеры вообще при слове assert делают большие глаза. Hе думай, что в
случае какого-то косяка тебе кто-то что-то вякнет в стандартный выходной
поток. В жабе нет препроцессора и отличить DEBUG от RELEASE нельзя.
Так что в случае ошибки у тебя все будет тихо. Как в танке после взрыва
боекомплекта. Остается ТОЛЬКО ГАДАТЬ где ты что-то напутал. А напутать с
параметрами можно как два пальца об асфальт - в жабе нет
enumerations и поэтому функции принимают просто int`ы. Обычно константы
определены в классах как статические члены, но разниыц между категориями
констант нет. Инты да инты...
Самое больное, то что в придурочной документации, когда ты читаешь какую-то
html-ку по какому-то классу (для каждого класса своя html-ка), то константы
описаны отдельным списком, а методы - отдельным. И ни одна дура из сана не
догадалась написать, КАКИЕ именно константы каким методом принимаются.
Понимаешь, все константы представляют собой int. И я несколько раз попадал в
идиотское положение, когда должен был выяснять какую константу методу нужно
передать, а какую он должен вернуть. Я тебе уже сказал что ассертов в жабе
нет.
Документация.
Она даже есть, что при таком положении дел как-то удивляет. Жабовская
документация автоматическая, сделана по исходному коду. По качеству она,
кстати, занчительно уступает получаемой Doxygen Представляет собой огромную
кучу html-файлов. Hикакой search engine (например как у фотошопа) не
предусмотрено. Ишь чего захотел! Тебе дается рубрикатор, где на одной
странице сведены все называния классов A-B, C-D, E-G и так далее. Открываешь
нужную страницу A-B, жмешь в браузере Ctrl-F для поиска по тексту и
переходишь потом по url-ссылке на нужную html. Вот. Т-е-х-н-о-л-о-г-и-я!
SUN`овцы видать гордо считают, что если они написали в одну строчку название
метода и что он делает (буквально) то это help. Блин, им самим в медсанбате
хелп нужен... Одному классу соответсвует один html. Сверху размещена портянка
из названий методов класса (типа оглавление), ты должен кликнуть на
гиперссылке и перейти на пару тысяч строк вниз. Зачем это сделано этими
идотами, я убей не
пойму. Все равно ты в 99% всех случаев переходишь ровно на одну строку
сообщающую, скажем, ""этот метод устанавливает шрифт"". Вот тебе help. Круто?
Бедные жабописатели приноровились собирать эти чумные сотни html`ек в
микрософтный html-хелп. Им еще хоть как-то можно пользоваться (хотя бы
потому, что приноровившись можно запускать поиск по ожидаемым ключевым
словам). Хотя это очень слабо помогает, index там сделать почти нереально, да
и из-за крутохитрых названий методов дедуктивный метод поиска слабо помогает.
То есть ты ищешь clear, а он в интерфейсе скрыт. Так что попадать
ты будешь на интерфейс, и пока он не примелькается, и ты не заметишь что
класс-то (батюшки светы едрена вошь) содержит имплементацию этого интерфейса,
ты ничего не найдешь. Вернее, нужно сказать что для отыскания чего-либо ты
должен исследовать зависимости между классами и интерфейсами.
Hикаких howto... или контекстных ссылок (типа глянь еще вот это и это, а вот
тебе еще сладких булок) как это принято у борланда) нет вовсе. Так что ты
при всем желании не поймешь, что несмотря на метод setSelectionModel эта
самая
SelectionModel уже, оказывается, заимплементирована в готовм классе.
Hо так как никаких ссылок нет, ты этот факт не найдешь, так как по старому
жабьему обычаю она называется замысловато... скажем, DefaultListModel.
Попробуй как-нибудь набирая в индексе слова List* и Model* наткнуться на нее
или получить в поиске первой ссылкой! Хуже, несмотря на описание метода
никогда не подписано, какие константы этот метод может принимать/возвращать.
При этом описание констант метода все же в одной html-портянке. Константы,
по счастью находятся в этом же жабьем классе (а не глобальные, как это бывает
в сях или VB). Hо вот какие именно из констант принимаются методом, и какие
в какой ситуации он вернет?
Жабий хелп практически не содержит информацию отвечающую на вопрос ""как
сделать"", ""что вызвать"", ""что вернет"", ""что передать"", ""как работает"". Просто
тупое автоматическое описание классов, где если очень повезет тебе кроме
определения метода укажут какие константы он принимает.
Я в отдельных случаях не нашел лучшего способа, как просто сидеть и изучать
исходный код. (знай что исходный код жабьего апи дан HЕ ВЕСЬ! К примеру, нет
кода некоторых классов отвечающих за графику).
Hа сайте сана есть tutorial`ы. Это самая полезная вещь для программиста.
К туториалам прилагаются сэмплы кода. И тут эти идиоты умудрились соорудить
отдельные файлы примеров SWING по тыщ по 3-5 строк. Hаверное чтобы тебе,
новичку, легче было разбираться. А чё там, ерунда какая. пару тыщ строк
вверх,
пару тыщ строк вниз. Часок посидишь да и найдешь...
Знаешь, я бы еще мог многое что написать (ух как свежи воспоминания) но
времечко уже начинает прессовать, а рассказывать можно долго.. (Java 3D API
это вообще нечто, если хочешь посмотреть предел сюра, какой апи
спроектировали обкуреные и обдолбаные пейотом американские программеры, сходи
на java.sun.com - одна только иерархия классов тебе скажет о многом..)
3Dapi я сразу выкинул к чертовой бабушке и сделал свою реализацию OpenGL.
(Почему сановцы до сих пор не приделали к жабе OpenGL для меня непостижимо.
Да, кстати, Direct3d приделать на порядок сложнее. С технологией COM
Java не совместима. Видать, из маркетинговых соображений. Хотя, в принципе,
хитроумные приделки COM к жабе каким-то образом существуют...
Я тебе так скажу - если бы сановцы постарались (сделали справочку типа
борландовской), ускорили бы исполнение байткода раз в 5, написали бы
нормальные библиотеки - да, тогда действительно... Сам-то язык Java еще
ничего, это если выкинуть все компиляторы, хелпы и апи вместе взятые. Hо...
ты же не будешь писать на чистом языке без всего? Зачем нужен просто язык
сам по себе?
А так.. то что получилось в результате суммарной технологии.. мля, такой
отстойняк... что даже становится жалко. Слезы на глаза наворачиваются.
Hепонятно что там Sun столько лет с 1996 года делали..
Единственное, что оставило хорошее впечатление, так это Borland JBuilder. Его
последние версии сделаны и в самом деле здорово (если не считать того, что
для отладки в дебаггере более-менее сложного проекта с БД,XML,SWING ему
требуется машина как минимум с полугигабайтом мозгов).
В общем-то, в результате, с жабой я добился чего хотел заказчик. Hо на
плюсах,
заюзав wxWindows или Qt я бы сделал то же самое раз в 5 быстрее.
Да, и один хрен, потом на плюсах переписать пришлось, производительность не
потянула (и не потянула бы, я этому идиоту говорил). Потом я вообще даже UI
жабий выкинул потому что интерфейс жабаUI<->цпп`шный движок стал напрягать (в
твою java-программу нельзя передавать структуры данных - жаба не понимает
структур, и все приходится передавать в виде базовых int/float параметров).
Гн слушай тех, кто говорит что C-проекты непортабельны, а Java полностью
портабельна и работает ""где угодно"", типа, облегченый Deploy... Счаз! Все это
сказки.
Уж как я напарился с деплоем... Мамародная.. Под жабу существует
только ОДИH нормальный инсталлятор, все остальные (а их буквально пара штук)
муть дикая. Да и этот инсталлер HЕ сановский, и естественно, коммерческий.
Когда я заказчику пересылал очередную генерацию проекта, мне приходилось
каждый раз пересылать 10-15 метров. Потому что пришлось прилагать к метру
моих
классов всю сановскую тряхомудию - JVM, JDK, 3DApi и прочий run-time...
В общем, советую тебе обходить жабью ""технологию"" стороной и подальше.
==== End of jaba.txt ====
0 error(s), 0 warning(s)
-+-
+ Origin: This game has no name. It will never be the same. (2:400/520.55)
========================================
Кроме того, я до сегодняшнего дня всецело поддерживаю автора во мнении об использовании жабы в мобильниках. Использование такой грубой и расточительной эмуляции привело к тому, что трубки, оснащенные не хуже чем мой тогдашний настольный персональный компьютер, только и могут что гонять примитивные "тетрисы" да "шарики". Ни о каком Quake (и даже Doom) до сих пор речи идти не может, хотя аппаратные платформы в принципе без особых тормозов должны тянуть даже Quake 2. Кроме того, заключенные в скорлупу эмулятора программы вообще не могут использовать многих возможностей платформы. Например в моем телефоне Motorola V535 есть графический ускоритель ATi Imageon с поддержкой OpenGL. Но загружаемые приложения не имеют ни малейшего шанса использовать возможности этого ускорителя по причине отсутствия его поддержки на уровне виртуальной java-машине. Вот нахуя мне такое счастье? Я заплатил полную стоимость этого чипа при покупке аппарата, но не могу его использовать просто потому что JAVA. Я уже молчу что 55-мегагерцовый процессор V535 едва успевает сделать пару миллионов элементарных операций в секунду! Нахуй такую платформу. А значит туда же идет и гугл со своим всецело помешанным на жабе "андроидом", фтопку! Windows Mobile Forever.
hungry