IBM и Oracle заявили (http://www.oracle.com/us/corporate/press/176988) о начале тесного сотрудничества в разработке Java-технологий. IBM подключилась к развитию открытого проекта OpenJDK, хотя ранее официально не проявляла к нему интереса и развивала вариант IBM Java 2 Standard Edition (http://www.ibm.com/developerworks/java/jdk/linux/), снабженный JIT-компилятором и виртуальной машиной собственного производства. Таким образом прокт OpenJDK становится первичной ареной для формирования открытой реализации платформы Java SE, языка Java, Java Development Kit (JDK) и Java Runtime Environment (JRE).
Более того, сотрудничество IBM и Oracle не ограничится OpenJDK: инженеры IBM начнут работать бок о бок с инженерами Oracle и сообществом независимых разработчиков над созданием эталонной реализации Java SE 7, формированием Java SE 8 и расширением процесса стандартизации Java Community Process (JCP (http://jcp.org/)).
Компания IBM лицензировала (http://web.archive.org/web/19990117025909/h...URL: http://blogs.sun.com/mr/entry/ibm_to_join_openjdk
Новость: http://www.opennet.me/opennews/art.shtml?num=28247
шавки лают, а караван идет
Да, такой толстый корован даже Гуглу не под силу ограбить.
А Оракл будет судится сам с собой из-за нарушений лицензий в ОпенЖДК? А если серьезно, странно, что они стали его развивать.
Поскольку Oracle владеет OpenJDK, то он может сам создавать себе лицензии на OpenJDK любого вида как только понадобится, потому сами они нарушить лицензии не могут - как только нарушили появится лицензия от Oracle разрешающая Oracle делать то, что они хотят ;)
OpenJDK лицензируется под GPL так что... скорее FSF с Ораклом будет судиться из-за нарушения GPL. =)
FSF!=GPL Если Oracle для кого-то лизензировали под GPL, то для себя они могут делать что хотят. Не путайте людей и не выдавайте желаемое за дествительное.
Хочешь загубить дело, возглавь его.
А помоему неплохая новость, лучше бы конечно эталонной реализацией была Apache Harmony... но.. чтож поделать... даже если теперь IBM и Oracle будут использовать одну и ту же версию Java... это уже будет круто... надоел зоопарк....
Ну в джаве зоопарка как раз нет.
За это надо, в общем-то, благодарить Сан, которые всегда настаивали на своей, эталонной, реализации языка.
ну это как посмотреть... я например наталкиваюсь периодически на несовместимость между Sun JDK и IBM JDK (используется для работы Websphere Application Server)...потому что на месте разработчика использую эталонную реализацию от Sun... а заставить её использовать продукты Websphere нет никакой возможности.
Еще добивают различию между Sun JDK и Open JDK (попробуйте запусти демки Apache Pivot под Open JDK).
Если хотя бы из этих 3х останется только OpenJDK то это уже будет праздник.Хотя конечно IBM предала сообщество Apache Harmony и компании которые помимо IBM её развивали.
Раз вложившись в Жабу, бросать не будут, даже если это самое наколеночное и убогое поделие. Отсюда понятен обоюдный интерес в улучшении Жабы, только... у меня такое ощущение, что Жаба не просто "отстала на 10 лет", а вообще осталась в прошлом веке. Про её ничтожную роль на Виндесктопе вообще молчу. Получается, этот "тихий супермен серверных комнат" помрёт, а никто даже не узнает. :)
Вы просто не имеете никакого понятия о степени использования Java в серверных (внутрикорпоративных разработках). Доля Java в Enterprise софте не просто огромна. Впринципе сейчас уже можно уверенно утверждать о лидерстве в этом сегменте рынка (имеется ввиду настоящий Enterprise софт, не Sharepoint'ы с Exchang'ами). Заметьте, если бы концепция была неудачной, врядли бы Microsoft клонировала данную технологию, а IBM и Oracle, Red Hat и Google так бы за неё цыплялись... Хотя.. конечно Вам виднее, какой технологии жить, а какой "помирать"...
Что касается виндесктоп, то там, как в прочем и на других десктопах (десктопы бывают не только Win не так ли). Рулят QT и GTK. Не уверен, что для Sun это было приоритетным направлением.
А вот то что рынок мобильного софта слит, эт да.. причем стараниями самой Sun...
> Вы просто не имеете никакого понятия о степени использования Java в серверных (внутрикорпоративных разработках). Доля Java в Enterprise софте не просто огромнаТак в том то и дело. Ынтерпрайз всегда был средой, состоящей из г%вна соединенного костылями, потому что бызинесу нужно чтобы работало вчера, на качество наплевать, о поддерживаемости кода вообще никто не думает, а насчет производительности - "если что, купим еще серверов". Поэтому да, java там идеально прижилась. Но это не значит что она применима в реальном мире, т.е. вне этой помойки. Собственно, (сюрпрайз!), она больше нигде и не применяется.
Как же утомили анонимные аналитики...
А ничего, что этот самый "Ынтерпрайз" как вы выражаетесь обеспечивает удобство в Вашей жизни по десяткам, если не сотням направлений. Начиная от работы банков в которых (сюрпрайз сюрпрайз... часто используются ESB, MQ в связке с Java (причем чаще всего с Websphere Application Server, Websphere ESB и т.д.)), заканчивая производствами (автомобилей, компов и т.д... большинство технологичных производств), добычей полезных ископаемых... выработкой электроэнергии.. производстве вооружения для армии и т.д.
Ничего что без этого Ынтерпрайза вы жить бы нормально не смогли, не говоря уже о том, что не могли бы спрятаться в своём маленьком Windows мирке... в котором все приложения такие замечательные и прямые??? По поводу производительности, качества и поддерживаемости кода, давайте не будете судить о том, чего не знаете?? Или расскажите это Apache Foundation, Google или RedHat... а то "мужики-то не знают"..За последнее время довелось поучаствовать в проектах в компаниях работающих в области энергетики, в банковском секторе, в машиностроении (автозаводы), добычи полезных ископаемых, в производстве движков для наших истребителей. И везде там использовалась Java, поскольку сравнимой платформы в данный момент просто не существует. Но конечно, люди работающие в этих организациях тупые неучи и бездари.. куда им до анонимных аналитиков...
>обеспечивает удобство в Вашей жизни по
>вы жить бы нормально не смогли, не
>довелось поучаствовать в проектах в компаниях работающих в области
>И везде там использовалась Java, поскольку сравнимой платформы"Давай, бухти дальше… как космические корабли бороздят просторы Большого Театра…"
>тупые неучи и бездари.. куда им до анонимных аналитиков...
По делу сказать нечего?
а что тут говорить? вы только размахиваете словом ынтырпрайз и всё.
банки говорите? а бтрив, прогресс до сих пор использующийся не хотите? а винду в банкоматах? думаете она туда за заслуги перед человечеством попала?
любой, хоть раз внедрявший что-либо в ынтырпрайзе на жабе (да и не только на ней) подтвердит, что это просто большая свалка дублирующегося много раз кода.
и потребности в повышенных потребностях в железе только увеличивают привлекательность таких проектов со стороны вендора.
> Раз вложившись в Жабу, бросать не будут, даже если это самое наколеночное
> и убогое поделие. Отсюда понятен обоюдный интерес в улучшении Жабы, только...
> у меня такое ощущение, что Жаба не просто "отстала на 10
> лет", а вообще осталась в прошлом веке. Про её ничтожную роль
> на Виндесктопе вообще молчу. Получается, этот "тихий супермен серверных комнат" помрёт,
> а никто даже не узнает. :)Вы не правы. Джава — не убогое поделие, а очень нужная и правильная разработка.
Более того, степень ее использования в определенном сегменте рынка растет и будет расти.
С технической точки зрения компилируемые языки вроде Си, Си++ и прочих будут потихоньку вытесняться именно языками на виртуальных машинах (Питон, Джава), поскольку они в целом удобнее для разработчиков.Просто до десктопов Джава пока не дошла целиком, в силу некоторых особенностей платформы и направления работы уже бывшей компании Сан.
Назовите хоть одно существующее в реальности преимущество именно VM (а не интерпретируемого языка) перед нативом.
> Назовите хоть одно существующее в реальности преимущество именно VM (а не интерпретируемого
> языка) перед нативом.большая легкость переноса на различные архитектуры
> большая легкость переноса на различные архитектурыЭто давно неактуально - мы живем в мире открытых исходников.
>> большая легкость переноса на различные архитектуры
> Это давно неактуально - мы живем в мире открытых исходников.Ну не скажите.. Если приложение изначально писалось как кросплатформенное, тогда да... Если нет.. то может возникнуть масса проблем...
Всё-таки Java приложение заработает на любом оборудовании без изменений, начиная с обычного ПК и заканчивая систем под управлением AIX, Solaris, HP-UX или вобще ZOs (мейнфреймы).
Примеров приложений например работающих только под линух немало в данный момент, что впрочем никак не умаляет значение opensource.
> Ну не скажите.. Если приложение изначально писалось как кросплатформенное, тогда да...
> Если нет.. то может возникнуть масса проблем...Которые элементарно обнаруживаются и фиксятся.
Алсо, несмотря на все обилие граблей, вероятность их появления сильно преувеличена, и требование - не писать кроссплатформенно, а просто писать нормально. Дай бог проценты из 22k портов FreeBSD собирались и тестировались под ARM и MIPS, тем не менее все что мне было нужно (и что я пробовал собрать ради интереса) собралось из коробки и замечательно работает.> Всё-таки Java приложение заработает на любом оборудовании без изменений, начиная с обычного
> ПК и заканчивая систем под управлением AIX, Solaris, HP-UX или вобще
> ZOs (мейнфреймы).На всем куда портировали JVM. А их много меньше чем вы думаете.
> Примеров приложений например работающих только под линух немало в данный момент
Примеры. Я десяток лет параллельно использую Linux и FreeBSD (на десктопе в том числе), и таких не назову.
> Дай бог проценты из 22k портов FreeBSD собирались и тестировались под ARM и MIPS, тем не менее все что мне было нужно (и что я пробовал собрать ради интереса) собралось из коробки и замечательно работает.Вобще сборка портов в FreeBSD на всех архитектурах - это задача portmgr.
Они должны следить что бы все собиралось и пинать маинтайнеров.
А вот работу - да, они проверять не могут.
>> Ну не скажите.. Если приложение изначально писалось как кросплатформенное, тогда да...
>> Если нет.. то может возникнуть масса проблем...
>Которые элементарно обнаруживаются и фиксятся."The main difference between theory and practice is, that in theory, there is no difference, but in practice, there is."
Знаем, плавали. Как только размер и сложность софта превышает определённый предел, а число разработчиков зашкаливает хотя бы за три человека, портирование даже между родственными (POSIX) платформами начинает представлять собой очень нетривиальную задачу. Изучено лично при сопровождении немаленькой системы, написанной преимущественно на C++, на платформах Linux, Tru64 UNIX и HP-UX. Даже перенос с HP-UX 11i v2 на HP-UX 11i v3 представляет собой весьма нетривиальную задачку.
в упомянутой ситуации точно такие же сложности и у жабы. к примеру - эрп-система от оракла - в серверной части жаба вроде всё нормально (после установки порядка овер 300 патчей, специфичных для конкретной платформы), клиент в виде жаба апплетов, где не работает колесо мыши, обязательно установка мс оффис и акробат ридера, при этом сама печатать отчёты она не может. при этом нужны jdk от 1.2.2 до 1.6, j2ee, oracle jnitiator. и у каждого свои глюки.
из всей системы самым портабельным является субд с pl/sql. да и то наверное потому, что ей не нужны ни графика, ни принтеры, ни прочее оборудование.
трухинский не портируемый дотнет вообще не рассматривается - даже если не учитывать сертификацию и прочий ынтырпрайзный шлак портирование на моно не тривиальна. пример paint.net, честное слово, быстрее бы на wine было.
зы:
>Знаем, плавали. Как только размер и сложность софта превышает определённый предел,..и да, по поводу портируемости с/с++ - системы на голом этнузиазме работают на такой куче платформ, что жабе и не снилось. расскажите об этом линухоидам, бздишнекам, гномовцам, ооо, не говоря уже про чуть более мелким - купсам, гутепринтам, гцц.
не возможность портирования говорить только об одном - шлак при разработке в головах ынтырпрайзовцев.
>> большая легкость переноса на различные архитектуры
> Это давно неактуально - мы живем в мире открытых исходников.перенесите мне пожалуйста вайн на арм
>перенесите мне пожалуйста вайн на армНет проблем, как только вы перекомпилируете все приложения которые хотите запускать при помощи вайн для арм.
А то ведь вайн в основном используется для пуска блобов.
Вы новости не читаете? Winelib работает под ARM, и открытый виндовый софт с ним замечательно сибирается. Я уже писал что это беспрецедентное событие, потому что другого способа нативно запустить виндовый софт под ARM нет. А про конкретно вайн уже сказали - нет проблем, только зачем, когда виндового софта под arm нет?
он на н900 уже давно работает.
и вопрос такой задавать вообще не корректно, т.к. виндовые проги разрабатывались не случайно не совместимыми, а специально.
и тем не менее они часто вполне прилично работают.
> Назовите хоть одно существующее в реальности преимущество именно VM (а не интерпретируемого языка) перед нативомпростота реализации сборщика мусора для VM, и вследствие того, возможность более активного использования first class object конструкций в языке, большую высокоуровневость языка, простоту управления памятью
1 простота реализации сборщика мусора для VM,
2 вследствие того, возможность более активного использования first class object конструкций в языке,
3 большую высокоуровневость языка,
4 простоту управления памятьюп.4==п.1, сборщик мусора не нужен, даешь великую тайну С++ - оператор delete
п.2==п.3, п.2 никак следствием п.1 не является, Perl, Python и PHP высокоуровневы без mandatory использования сборщика мусора. Да, он там есть, но при правильном написании не используется ==не нуженИтого: высокоуровневым языкам и возможностям - Да!
Сборщику мусора - Нет!
> п.2==п.3, п.2 никак следствием п.1 не является, Perl, Python и PHP высокоуровневы!=. Без этого нормальные замыкания не реализовать, а какая тогда высокоуровневость?
> п.4==п.1, сборщик мусора не нужен, даешь великую тайну С++ - оператор deleteили функция free() в C. Я согласен - garbage collector это для лентяев и тех, кто пишет неаккуратно
> Назовите хоть одно существующее в реальности преимущество именно VM (а не интерпретируемого
> языка) перед нативом.Если, по-вашему имеется у интерпретируемого языка преимущество перед натив-кодом, то
слежующий же шаг инженера языка - оформить промежуточный код интерпретируемого языка
в разумный промеуточный код (p-код, байт-код). Это просто логично - не перекомпилировать каждый раз. особенно большие проекты и особенно библиотеки.
Такое преимущество существования VM. при условии:Назовите хоть одно существующее в реальности преимущество именно интерпретируемого
языка перед нативом.
> Просто до десктопов Джава пока не дошла целиком, в силу некоторых особенностей
> платформы и направления работы уже бывшей компании Сан.в силу того, что gui писать на java сейчас очень убого, будь то swing, swt, awt, flex, javafx или что-то еще. это была причина моего возвращения на .net
ларри запил, а балмер продолжает прыгать.
А интересно какие это такие разногласия с компанией Sun Microsystems, которые были исчерпаны после перехода Java в руки Oracle.
> А интересно какие это такие разногласия с компанией Sun Microsystems, которые
> были исчерпаны после перехода Java в руки Oracle.Oracle умеет договариваться)
Может допилят Eclipse и OpenJDK дл нормальной производительности. Ато Eclipse на OpenJDK тормозит заметно больше...
странно. я думал что то что есть в OpenJDK - открытые части JDK. Или там код все-таки разный?
насколько мне известно оно полностью соответствует JDK 7 по коду.. т.е. это бекпортирование открытых кусков кода JDK 7, соответствующих по функционалу JDK 6.. как-то так..
полное соответствие кода JDK и OpenJDK будет к моменту пришествия JDK 7.. по крайней мере обещают так...
круто. меньше зоопарк, лучше получится технология. а то с переносом выхода JDK и урезанием возможностей в Java совсем грусно. Очень жду JavaFX 2.
Эх... Не уживутся IBM с Оracle в одной упряжке. Готов поспорить, через полгода, максимум год, их союз развалится и IBM возьмется за Apache Harmony. Но идея неплохая..
На сколько спорим, что до 12 октября 2011 года не распадётся?
Более того, будет массивное вливание кода в OpenJDK.