Здравствуйте, Uzumaki Naruto, Вы писали:
UN>Мда... Вижу что вы просто не работали под Linux и не программировали под него...
Вы телепат? Нет. Тогда чего придумываем.
Вы меня знаете, чем я занимаюсь? Может я повар и зашел сюда по тусоваться и о Windows/c++/Linux/Java от соседа услышал.
Если не знаете, чего пишите?
PS. Типичная, черта российских форумов переход на личности и выводы из ничего.
UN>Во первых не ошибок, а я привожу аналоги, а не точную копию — просто вы не делали подобных вещей на С++, а я делал.
Да на C++ действительно давно не писал. Но COM/ActiveX-компоненты приходилось писать, приходилось... И именно на C++. Так что это вы зря.
UN>Во вторых — Hibernate использует JBDC, а тот в свою очередь OBDC... Я это утверждаю с 100% уверенностью — почитайте документацию... Так же я утверждаю, что JBDC использует OBDC (!!!!) через драйвера (!!!!)
JDBC использует ODBC? Итересное утверждение. А можно ссылочку в студию, где это написано?
А еще краткий разрул, как же оно это делает на платформе Solaris, например. Желательно для такой популярной базы, как Oracle. Для полноты картины, так сказать. А то я шесть лет работал с Java, а вот ни разу ODBC-драйвер на солярку не поставил. Не тот JDBC использовал, видать...
И, кстати, JDBC, а не JBDC. И ODBC, а не OBDC.
UN>Не делайте из других идиотов, перевирая их слова.
Упаси Боже! Я ни из кого не хочу делать идиотов. Просто указал на то, что ваши утверждения были по сути не корректны, а аналогии не правильны. Вот и все.
MR>JDBC использует ODBC? Итересное утверждение. А можно ссылочку в студию, где это написано? MR>А еще краткий разрул, как же оно это делает на платформе Solaris, например. Желательно для такой популярной базы, как Oracle. Для полноты картины, так сказать. А то я шесть лет работал с Java, а вот ни разу ODBC-драйвер на солярку не поставил. Не тот JDBC использовал, видать...
Ну например так — http://java.sun.com/products/jdbc/faq.html#2
Кстати может быть я выразился не так — JDBC может использовать ODBC — а может и нет — но часто для MSSQL и MySQL использует. Для Oracle используют реже, хотя есть OBDC драйвера и для Oracle.
MR>И, кстати, JDBC, а не JBDC. И ODBC, а не OBDC.
Каюсь — постоянно печатаю не так... В голове мыль по русски идет — по этому БД, а не DB =)
Здравствуйте, Uzumaki Naruto, Вы писали:
UN>Ну например так — http://java.sun.com/products/jdbc/faq.html#2 UN>Кстати может быть я выразился не так — JDBC может использовать ODBC — а может и нет — но часто для MSSQL и MySQL использует. Для Oracle используют реже, хотя есть OBDC драйвера и для Oracle.
UN>Ну например так — http://java.sun.com/products/jdbc/faq.html#2 UN>Кстати может быть я выразился не так — JDBC может использовать ODBC — а может и нет — но часто для MSSQL и MySQL использует. Для Oracle используют реже, хотя есть OBDC драйвера и для Oracle.
Вот именно, что не так. Обычно ODBC-то как раз и не используется. Ссылка, которую вы дали, указывает на так называемые JDBC-ODBC Bridge. А это частный случай, не более. Для Oracle, MSSQL, My SQL, Postgres, etc всегда используются родные дрова (сами подумайте, зачем нужен платформенно зависимый и не очень надежный дополнительный слой). А указанный вами Bridge я лично использовал всего один раз, когда для Windows-платформы требовалась поддержка FoxPro какой-то уж совсем древней версии, для которой JDBC-драйвера по упределению не было.
Если бы вы имели реальный опыт работы с Java, вы обо всем об этом знали бы уж сто пудово. Ибо даже для Junior Developer'а, работающего полгода, все эти нюансы были бы уже давно очевидны. Кстати, когда я в свое время пошел в Java, то первая задача, с которой я столкнулся — это был именно доступ в Oracle через JDBC. Hibernate тогда еще не существовал.
На основании всего этого я и сделал вывод, что с Java вы, скорее всего, знакомы только по статьям в Инете и разговорам коллег. А сертификат, которым вы хвалились в предыдущих постах, вами был скорее всего получен после подготовки "по учебнику", а не после реальных проектов.
Это верно лишь отчасти. У Oracle есть две версии JDBC-драйвера: толстая и тонкая. Толстая использует оригинального ораклового клиента, т.е., по сути, я вляется Java-оберткой вокруг него. Тонкая же — это pure реализация NET8/NET9 протоколов на Java. В 90% проектов, где я участвовал, использовалась именно тонкая версия из-за высокой переносимости между платформами и отсутствия заморочек с установкой ораклового клиента.
В остальных случаях, где производительность в силу ряда причин была особенно критична, использовался толстый драйвер.
О, holy war! Java vs. C++, обожаю. Been there, done that. Оба языка, обе группы технологий, хороши и интересны. На Java писать проще и намного приятнее, т.к. само окружение удобнее, позволяет не заботиться о назойливых мелочах вроде выделения-освобождения памяти. И в целом, после С++ сесть на Java — это как после машины с МКПП вдруг получить современную продвинутую АКПП. (Ну или роботизированную КП, если это С# ). Само собой, выжать всё из машины на АКПП не выйдет — коробка тупит, даже самые продвинутые пока еще не имеют телепатической связи с водителем, и потому МКПП на большинстве экстрим-применений рулит. Но в повседневной жизни "автомат" проще. Вот его и используют. Перелезть с МКПП на автомат — да влёгкую. У меня даже минуты не ушло. Сразу поехал, будто всю жизнь на автоматах ездил. Аналогично с роботом. Ну, а сколько я МКПП осваивал, я лучше умолчу, стыдно будет.
В другую сторону — ощутимо сложнее. Знакомый один с праворульки на автомате перелез на леворукую приспортивленную машинку с МКПП. Недели две вождение было для него кошмаром. Потом ничего, освоился. Но теперь при встрече говорит, что следующая его машина будет только с автоматом Потому что в повседневной жизни автомат удобнее.
Так же и с языками. Java проще, удобнее, более programmer-friendly. Это, если угодно, попса. Нечто усредненное. И сделано оно вовсе не для комфорта и удобства разработчиков, а тупо для снижения затрат времени на разработку. В том числе и потому, что дает возможность брать разрабтчиков с меньшей квалификацией. И они не смогут тотально нарушить работу проекта — java не позволяет этого. Там куда сложнее прострелить себе ногу. В С++ — пожалуйста. И чтоб на нем писать надёжный софт, нужно действительно уметь это делать.
Здравствуйте, SkyDance, Вы писали:
SD>О, holy war! Java vs. C++, обожаю.
Объясните мне, тупому. Как можно воевать на уровне Java vs C++ vs C#? Я понимаю, если взять какую-нибудь конкретную задачу, типа корпоративной системы или драйвера под Линукс, под нее выбрать несколько вариантов решения задачи и аргументированно спорить, какой solution лучше. Но как можно спорить на тему языков? Особенно, если учитывать, что они идут, как бы, в комплекте с фреймворками и прочим, и по большей части выбирая решение задачи, автоматом выбирается и язык.
Вот, например, надо сделать клиента для веб сервиса. Нужен он в виде веб-морды? Нет, нужно нормальное приложение. Должно оно быть кросс-платформенное? Нет, только под винды. Что будем использовать — winforms, swing, qt или mfc (если бы нужна была кроссплатформенность mfc и winforms ушли, а вот mono уже можно было бы рассматривать)? qt или mfc? тогда пишем на C++. swing? java без вариантов. winforms? c# или vb.net?
Т.е. выбор собственно языка — это последнее дело при выборе решения задачи и по большей части это выбор предопределен. Поэтому меня и удивляют оторванные от контекста споры о том, какой язык круче.
Здравствуйте, olegkr, Вы писали:
O>Здравствуйте, SkyDance, Вы писали:
SD>>О, holy war! Java vs. C++, обожаю. O>Объясните мне, тупому. Как можно воевать на уровне Java vs C++ vs C#?
Я и не воюю, просто этот человек пытается мне доказать, что в Java есть то, чего нет в C++. Я же доказываю обратное, все есть. Человек просто не знает глубоко реалиаций разных технологий на С++ и часто многое в Java сделано из С++ реализаций, иногда даже так бывает, что Java реализации бывает чаще используются, чем С++.
Здравствуйте, Uzumaki Naruto, Вы писали:
O>>Что? Неужели уже J2EE, Hibernate, сервлеты и прочая-прочая-прочая портировал на С++? Как я отстал от жизни, уважаемый "не юнец", написавший тонны кода на жабе UN>Да неужели... для J2EE есть в Win32 аналог называющися COM+ и DCOM не получившие распространения
Так ты задумайся ПОЧЕМУ они не получили распространения.
На Java для создания аналога DCOM-сервиса мне надо написать пару строк в конфиге Spring'а. Для создания аналога COM+-сервиса — нужно просто написать EJB3-бин.
В DCOM нужно было делать танцы c регистрацией, IDL и т.п. COM+ так вообще требовал запредельной сложности при программировании на С++ (нужно было реализовать кучу интерфейсов и т.п.). Причем если все это счастье не работало — то обычно непонятно вообще было где оно глючит.
UN>а если взглянуть на тот же apache — чем тебе не аналог J2EE сервера...
Это примерный аналог. В нем нет фильтров, контекстных слушателей, поддержки сессий (в том числе расределенных) и т.п.
UN>сервлеты ... когда их еще не было, серверные скрипты писались на чистом С и чуть позже появилось ISAPI для IIS, в Apache есть тоже много полезного.
Полностью того же — нет, или делается достаточно сложно.
UN>А про Hibernate — все в Java используют замечательную вещь OBDC, давным давно все запросы к разным базам были универсальными, но это было давно и не правда =)))))
Мда. Прости, но работаешь ты с Java либо в очень узких областях, либо очень мало.
Во-первых, ODBC не дает возможности писать DB-независимые запросы (за исключением тривиальных). Во-вторых, Hibernate делает еще оооооооооооооочень много помимо запуска запросов. В-третьих, никто почти не использует ODBC-JDBC мост в Java — так как нафиг это никому не нужно (JDBC-драйвера доступны для большинства баз, для MySQL и Oracle они вполне нормальны), я лично его использовал только один раз для подключения к Access'у.
Java дает огромную гибкость и кучу полезнейших инструментов разработки. Один Maven с его мегарепозиторием открытых проектов чего стоит...
C>Так ты задумайся ПОЧЕМУ они не получили распространения.
Но это не повод говорить, что этого нет =))))) Я на этом делаю акцент.
C>Java дает огромную гибкость и кучу полезнейших инструментов разработки. Один Maven с его мегарепозиторием открытых проектов чего стоит...
Никто с этим не спорит, но так как все в свое время кинулись в Java — сделали удобней в Java, но реально тоже самое можно было бы сделать и на С++ — так же удобно, просто возник вопрос — нужно ли тратить кому-то силы и ресурсы, когда проще заюзать готове... Просто это не аргумент в споре — что С++ устарел, а Java круто или С# — если потратить ресурсы — C++ даст результат не хуже, а даже лучше Java, да и сама JAVA VM на чем написана? А ? =))))))))
Здравствуйте, Uzumaki Naruto, Вы писали:
C>>Так ты задумайся ПОЧЕМУ они не получили распространения. UN>Но это не повод говорить, что этого нет =))))) Я на этом делаю акцент.
Ну на практике — сейчас почти нет. CORBA/DCOM — это практически только поддержка старых систем и некоторые ниши (CORBA в телекоме любят, например).
C>>Java дает огромную гибкость и кучу полезнейших инструментов разработки. Один Maven с его мегарепозиторием открытых проектов чего стоит... UN>Никто с этим не спорит, но так как все в свое время кинулись в Java — сделали удобней в Java, но реально тоже самое можно было бы сделать и на С++ — так же удобно, просто возник вопрос — нужно ли тратить кому-то силы и ресурсы, когда проще заюзать готове... Просто это не аргумент в споре — что С++ устарел, а Java круто или С# — если потратить ресурсы — C++ даст результат не хуже, а даже лучше Java, да и сама JAVA VM на чем написана? А ? =))))))))
Так как раз проблема в ресурсах — на С++ enterprise-приложения писать сейчас просто глупо. Куча дополнительных ресурсов будет потрачена зря.
Еще раз говорю — первое не хамите — Я с Java работаю более 7 лет.
Теперь по порядку... ODBC — Open Database Connectivity — это стандарт. Есть как Win32 реализация ODBC, так и UnixODBC реализации, а так же iODBC и UODBC. Когда делался JBDC — он полностью повторил собой функциональность ODBC. Так как драверов JDBC еще не было написано, был написан JDBC-ODBC мост. Так что JDBC вырос из ODBC — из C++, так что не надо говорить, что на C++ ничего нет — оно как раз выросло из C++. Аналогично и Hibernate вырос из аналогичного С++ проекта, который правда не получил свое время развития, потому что все кинулись из-за модности в сторону Java, но на С++ это тоже есть.
Если вы не работали ни с чем, кроме Oracle — где это не используется, то это не повод говорить, что не может быть реализовано по другому и пытаться уличить других в невежестве, ибо тем самым вы показыаете только свою узкую сторону знаний, — драйвера JDBC дают свободу творчества и могут использоваться не только для доступа к базам данных... Вы когда нибудь писали свой драйвер JDBC? А я писал.
Здравствуйте, Uzumaki Naruto, Вы писали:
C>>Так как раз проблема в ресурсах — на С++ enterprise-приложения писать сейчас просто глупо. Куча дополнительных ресурсов будет потрачена зря. UN>Согласен, что глупо, просто я делаю акцент, что на С++ это тоже есть, есть и коммерческие C++ enterprise сервера...
Вопрос тут не только теоретический, а еще и практический. Практически — полноценной целостной инфраструктуры наподобии JEE для С++ нет (и уже не появится).
При большом желании можно что-то свое написать из имеющихся систем — но это уже будет в большинстве своем бездарной тратой времени.
UN>Это все ответ на цитату от olegkr: UN>
Неужели уже J2EE, Hibernate, сервлеты и прочая-прочая-прочая портировал на С++?
UN>Это еще вопрос — кто у кого что позаимствовал...
Пожалуй, полноценного аналога Hibernate все же нет.
C>Пожалуй, полноценного аналога Hibernate все же нет.
Согласен, да он и не нужен, я полагаю. Это всего лишь вспомогательное в проектах, а вспомогательные вещи как раз можно и на Java писать, что собственно и делается.
Здравствуйте, Дмитрий В, Вы писали:
I>>Присоединяюсь в вопросу и добавляю еще один: Почему OpenOffice не на Java? ДВ>Не надо гнать, интерфейс там — свинговый. (swing — графическая библиотека на java).
OpenOffice.org в основном написан на C++. Если будешь спорить, найду тебе ссылку. Только давай не просто так спорить; например, кто проиграет, выполняет мелкое поручение другого. Ты в России живешь? Мне гадский ozon.ru не посылает CDs, заграница говорит, а частные посылки на почте наверное не обязательно проверяют. Итак, OpenOffice.org в основном написан на C++, спорить будешь?
Здравствуйте, Uzumaki Naruto, Вы писали:
UN>Кстати может быть я выразился не так — JDBC может использовать ODBC — а может и нет — но часто для MSSQL и MySQL использует. Для Oracle используют реже, хотя есть OBDC драйвера и для Oracle.
Да, теперь ближе к истине... А я то, болезный, думал, что детали реализации драйвера JDBC — up to its developer. Хочу — на яве native-драйвер для Оракла напишу, который за собой ничего, кроме jar-ок не тянет, хочу — в виде бинарных модулей нарисую, которые через JNI дергать из драйвера буду (но тогда писать мне их для каждой платформы). Ну и т.д.
