Все новости от 16 марта 2005 г.

Sun намерена подсластить Java

Новый курс в области лицензирования нацелен на то, чтобы предоставить разработчикам больше возможностей по использованию исходного кода Java. Однако, по словам представителей Sun, это не означает, что Sun намерена сделать Java доступной по лицензии open source, как утверждают некоторые сторонники Java.

Джеймс Гослинг, главный технолог отделения Sun Developer Products, пообещал рассказать о новом подходе к лицензированию на пресс-конференции в среду.

Если лицензионные ограничения будут ослаблены, это может облегчить использование Java с программным обеспечением open source, особенно Linux, отметил аналитик RedMonk Стивен Огрейди. «Разрыв между коммерческими и некоммерческими приложениями все больше сужается, так что движение в направлении общего ослабления лицензионных ограничений не удивительно», — сказал он.

Sun контролирует лицензию, которая регламентирует использование языка программирования Java и программного обеспечения, необходимого для работы Java-программ. Коммерческие компании, такие как IBM и Oracle, используют Sun Community Source License (SCSL). В 2003 году Sun ввела лицензию Java Research License (JRL), поощряющую исследования в области Java в академических учреждениях.

Теперь Sun работает над отдельной инициативой по пересмотру коммерческой лицензии Java. «JRL — некоммерческое упрощение SCSL, и теперь мы оцениваем, как упростить SCSL для коммерческих целей, — говорит директор по маркетингу продукта Sun Java 2 Standard Edition Джин Эллиот. — Хотелось бы, чтобы коммерческая лицензия со временем вовсе исчезла, как хвост у человека, потому что мы чувствуем, что она слишком переусложнена».

Компании, которые продают продукты на базе Java, а также сторонники ПО open source пристально следят за политикой Sun в отношении Java. В прошлом году IBM обратилась к Sun с открытым письмом, в котором утверждала, что компании следует лицензировать ПО Java по лицензии open source. Sun отказалась, отчасти из-за того, что это может привести к несовместимостям в стандарте Java.

Mustang появится на свет в следующем году
Как сообщил архитектор J2SE и главный инженер Sun Марк Рейнхольд, ПО для создания и исполнения Java-приложений Java 2 Standard Edition с кодовым названием Mustang должно быть готово к середине 2006 года.

ПО J2SE, которое используется главным образом для создания приложений для настольных ПК, служит основой спецификации Java для серверов, называемой Java 2 Enterprise Edition. Обновление этого стандарта, J2EE версии 5.0, планируется выпустить во втором полугодии 2005 года. Следующее обновление J2EE ожидается по завершении работы над Mustang.

В Mustang не будет столь значительных изменений, как в версии J2SE Tiger, которая вышла в сентябре прошлого года. Однако она принесет важные усовершенствования, говорит Рейнхольд. Ожидается, что все подробности о планируемых функциях станут известны в ближайшие два месяца.

В Mustang Sun хочет гарантировать совместимость Java-приложений с существующими программами и упростить диагностику и поиск ошибок. ПО для написания программ, соответствующих протоколам веб-сервисов, которое сейчас предлагается в качестве дополнения, будет переработано и включено в состав J2SE.

В Mustang планируется также упростить процесс Java-программирования и облегчить включение программ, написанных на языках сценариев, таких как Perl, Python или PHP. Туда войдет и ПО, созданное рабочей группой Java Specification Request 223, которое позволит воспроизводить в приложениях Java-сервера веб-страницы, созданные при помощи сценариев.

В процессе разработки Mustang компания Sun будет выпускать исходный код и двоичные версии ПО по мере готовности, вместо того чтобы предложить их единым пакетом после завершения разработки, сказал Рейнхольд. Компания планирует регулярно, каждые два месяца, выпускать обновления для Mustang, исправляющие ошибки и вносящие другие изменения.

До сих пор капитальные обновления ПО Java выходили каждые два-три года. Sun перешла на более плотный график потому, что существующая система «не позволяет нам двигаться в том темпе, в котором хотелось бы, особенно на фоне конкурирующих платформ, таких как Microsoft .Net», — сказал Рейнхольд. 

 Предыдущие публикации:

 В продолжение темы:

Обсуждение и комментарии

	pto - ptokgb.ru 16 Mar 2005 10:17 PM
Типа дерьмо мёдом не испортишь :)
	aiz 17 Mar 2005 11:52 AM
ТАКОЕ - испортишь и медом!
	iZEN - izenmail.ru 17 Mar 2005 4:03 PM
Ну, если бы Java быыла свободной, то очень быстро стала бы "несовместимой". Продукт не может сам позаботиться о своей неповторимости - всегда найдутся разные люди, которые обязательно улучшат его в том или ином направлении. MS, например, непрерывно улучшает свою "стандартизованную" среду исполнения .Net Framework так, что каждые полгода-год выходят несовместимые релизы, от старых приходится отказываться и переписывать всё заново. Java совместима снизу вверх по версиям начиная с 90-х годов - по крайней мере перекомпилировать так часто не нужно большую часть кода, написанную по правилам языка/технологии, исключая "узкие моменты". В конце-концов, есть JCP.org - стандартизующий отраслевые Java API.
	Black Bat 17 Mar 2005 5:05 PM
_MS, например, непрерывно улучшает свою "стандартизованную" среду исполнения .Net Framework так, что каждые полгода-год выходят несовместимые релизы, от старых приходится отказываться и переписывать всё заново. _ вот только 3.14-здеть не надо!!!
	уних world - s999999999rambler.ru 17 Mar 2005 5:23 PM
За что ты его так? По мне , что java что Net ( переименованная java) всё одно ...но.
	Wintermute - devnul.ru 18 Mar 2005 11:52 AM
За то, что врет, и не краснеет.
	Боровой 18 Mar 2005 3:24 PM
2 уних world ну, тады поведай нам о другом ...не, которое для тебя предпочтительней
	iZEN - izenmail.ru 18 Mar 2005 8:15 PM
Что ж, читайте: In general, I think the library was released too early, and I think it was too large. The framework redistributable is 25 MB, which is many times larger than the Java redistributable. и это Richard has used .NET for five years, he was on the technical preview for COM+2 which was the technology that eventually became .NET. Richard has decided to break his link with .NET, this site will continue to contain the free .NET resources that Richard has produced over the last 5 years, but Richard will no longer be available to do any more work on .NET. He will not write any more .NET articles, no more .NET books and will no longer speak at .NET conferences Источник: http://www.ddj.com/documents/s=9211/ddj050201dnn/ Обсуждение: http://www.rsdn.ru/Forum/Message.aspx?mid=1065355&pg=1
	Black Bat 18 Mar 2005 9:36 PM
_The framework redistributable is 25 MB, which is many times larger than the Java redistributable_ http://java.sun.com/j2se/1.4.2/download.html 50 мб это как раз то БОЛЬШЕ, чем .net так что ещё раз повторяю - кончай 3.14...ть!
	Имя 20 Mar 2005 12:06 AM
2 Black Bat > http://java.sun.com/j2se/1.4.2/download.html > 50 мб > это как раз то БОЛЬШЕ, чем .net > так что ещё раз повторяю - кончай 3.14...ть! Ты дал ссылку на SDK. Ты хоть знаешь, что это такое, граматей? SDK кроме виртуальной машины в себя включает так же средства разработки, компилятор, примеры, документацию и (о боже!) исходные коды джавы. .NET SDK занимает 111Мб, сам только что посмотрел. Сам же framework redistributable занимает 15Мб, ищи его здесь: http://java.com/en/download/windows_xpi.jsp Так что, эта ... кончай 3.14...ть!
	Black Bat 20 Mar 2005 4:40 PM
to Имя: ты сначала техникум закончи, да! компиляторы C#, VB.NET, J#, подержка ASP.NET, плюс куча различных утилит для девелопмента входит в в эти 23 МБ Framework-a
	iZEN - izenmail.ru 22 Mar 2005 9:59 AM
Размер причём здесь? JRE занимает меньше 20Мб и, в отличие от громоздкой .Net Framework, не требуется ничего больше устанавливать на компьютер пользователя (как-то: поддержка "новой версии" ADO не у всех есть - надо качать, IE6 не у всех есть - надо качать, MSXML не у всех есть - надо качать и т.д.). Для разработчика Java достаточно порядка 300Мб (JDK, JavaDOC, IDE какая-нить). Для .Net-разработчика нужна целая инфраструктура на семи(если не больше!!!) CD-дисках, включая MSDN-library.
	eXOR 23 Mar 2005 5:01 AM
Oak как проект был создан непонятно для чего. Для интеграции различной периферии? Так кажется? Ну так вот и имеем продукт без ниши, который стараются впихнуть куда ни попадя (самое оптимальное в телефон/смартфон) в результате несмотря на многие технические преимущества Java до сих пор всегда находится в состоянии догоняющего (то догоняет C++ в производительности, то догоняет C#, то теперь уже догоняет PHP) хотя при правильном позиционировании в роли догоняющих были бы все остальные. В этом плане .NET как продукт гораздо лучше позиционирован - поскольку это платформа для разработки web services.
	iZEN - izenmail.ru 23 Mar 2005 2:45 PM
eXOR, чего догоняет?! Сервера приложений J2EE учитываете? Какое нафик PHP! PHP НЕМАСШТАБИРУЕМАЯ технология. Кластеры на PHP кто-нибудь видел? Смартфоны с J2ME сейчас занимают 95% аппаратов, если не больше. Это наиболее свободная технолгия по сравнению с Mophun и т.д.
	iZEN - izenmail.ru 23 Mar 2005 2:47 PM
Что имеем на сегодня: уродский C++ с переполнениями буферов и лекарствами для этого (антивирусы) везде. Страуструп совершил болшую ошибку, разработав сырой язык.
	Имя 23 Mar 2005 3:48 PM
2 Black Bat >ты сначала техникум закончи, да! ух ты, ну что поделать, пойду поступать в техникум... >компиляторы C#, VB.NET, J#, подержка ASP.NET, плюс куча различных утилит для девелопмента входит в в эти 23 МБ Framework-a да знаю я то в него входит, что ты меня лечишь? Придурок, не сравнивай SDK и Runtime Environment. Любой из этих у .NETа по размеру больше. Другое дело, имеет ли это значение...
	eXOR 25 Mar 2005 7:59 AM
2 iZEN: > Сервера приложений J2EE учитываете? Конечно учитываю. И количество тендеров на Java (JWS/J2EE) и количество квалифицированых кадров. > НЕМАСШТАБИРУЕМАЯ технология. Как всегда... доводы одни и те же. Хороший разработчик в любой технологии найдет плюсы, плохой в любой найдет минусы. Масштабируемость даже в самых сложных проектах нужна далеко не в каждом модуле. И критичные места всегда можно реализовать так, чтобы они работали максимально эффективно. > Что имеем на сегодня: уродский C++ с переполнениями буферов Низкое качество кода <= низкое качество работы исполнителей <= низкое качество работы среднего звена. Доучивайте/тесь, стимулируйте итд.