Глава Sun Microsystems пообещал (http://www.infoworld.com/article/06/06/27/79685_HNsunopensou...), что исходные тексты Java 1.5 будут раскрыты под одной из open-source лицензий в ближайшие несколько месяцев.
Главной проблемой остается задача предотвращения дробления проекта и создания множества несовместимых клонов, на базе открытых исходных текстов. Представители Sun опасаются, что некоторые компании смогут начать продвигать свои наработки, не обеспечивающие полной совместимости, нарушив при этом главный принцип Java - "написал один раз - работает везде".URL: http://www.infoworld.com/article/06/06/27/79685_HNsunopensou...
Новость: http://www.opennet.me/opennews/art.shtml?num=7802
Какая разница сколько осталось до открытия исходных кодов жабы? ничего от этого не изменится... а пройдет еще лет 5 и эта жаба пойдет в мусорку, а мы с вами на пенсию.
однако оптемист вы батенька
зря вы так батенька
java+linux rules
получаются очень простые и работающие решения
python + freebsd -- более наглядные и простые решения...
не нада ее открывать
Ну конечно... Тот же класс Properties с его ISO кодировкой достал...
до дня рождения А.С. Пушкина осталось 135 дней...
Пускай открывают! Нарушиццо принцип "написал раз - глючит везде"... Вапще работать перестанет.
Не представляю IT без Java. Пусть открывают. Сановая реализация все-равно де-факто стандарт, тем более что даже сейчас много разных (не 100% совместимых) реализаций. Так что сильно хуже не будет. Главное юзать с умом. Вот :)
Лучше бы держали в закрытом виде. По примеру - Вполне хватает открытого linux ядра, любая группа людей может создать и открыть свой дистр на основе linux ядра, напихать пакетами со своими патчами и опять на рынке появляется новый дистр, - часть людей переходит на новый дистр, часть людей остаётся юзать и участвовать в разработках старшего продукта, но численность над старшим продуктом теряется.Такое может произойти с java машиной, когда каждый будет брать исходный код и баянить по свойму, начнётся беготня к каждому продукту для тестирования и находить наиболее лучшую сборку, большая часть народа разделятся на половинки использую другие java машины, а не старшего/основателя cамой машины, который можно совместно доводить до самой гигансткой стабильности, помогая SUN`у через всяческого рода community.
Может с другой стороны лучше, что код будет открытый, но я не могу зацепится - что полезное принесёт данное открытие.
и что теперь программы , со -static собранные, работают ТОЛЬКО на каком-то одном дистрибутиве ? Не верю
польза - это как раз и есть N форков жабыконечно все расползуццо куда кому нравицо
так в этом то и прелесть! Все не будут по-старому сидеть и ждать маны Sun'овской.
А вдруг у кого есть идеи, которые не реализовать с нуля (долго, проблемно), а на основе кода жабы - появиццо конфетка!? РЫНОК! Борьба! Конкуренция!
Это еще никогда не делало положение вещей хуже ;)Задумайся....
> Может с другой стороны лучше, что код будет открытый, но я не могу зацепится - что полезное принесёт данное открытие.Если не закроют патентами, а действительно выложат в свободное пользование - представляешь сколько там алгоритмов/наработок.
Один JIT компиллер (второй после .NET Framework) чего стоит.
Ты любишь PHP? или Perl? или Python? или Ruby? А теперь представь, что их можно ускорить в 2-4 раза (а PHP с Ruby и в 8-10) заимствуя наработки программеров SUN.Ну а для SUN Java - сотни бесплатных кодеров, ищущих ошибки, тестирующих варианты оптимизации. У Microsoft больше народу - .NET Framework вышла пошустрее (не много - раза в полтора-два-три- точно кто-нить скажет? Но не в десять). Глядишь, с помощью коммунити Java его догонит.
> Один JIT компиллер (второй после .NET Framework) чего стоит.
почему второй ? просто в .NET богаче байткод соотвественно "компиллер" меньше "думает", а больше знает точно, но это все равно не спасает его от java -server> Ты любишь PHP? или Perl? или Python? или Ruby? А теперь представь, что их можно ускорить в 2-4 раза (а PHP с Ruby и в 8-10) заимствуя наработки программеров SUN.
php нет :)Why your own virtual machine? Why not compile to JVM/.NET?
Those VMs are designed for statically typed languages. That's fine, since Java, C#, and lots of other languages are statically typed. Perl isn't. For a variety of reasons, it means that Perl would run more slowly there than on an interpreter geared towards dynamic languages.
The .NET VM didn't even exist when we started development, or at least we didn't know about it when we were working on the design. We do now, though it's still not suitable.
"просто в .NET богаче байткод" - чемто мне это напоминает противостояние RISC и CISC технологий - в CISC 50% инструкций не используется.
> ничего от этого не изменится...
А скорость работы от оптимизации при компиле под данную платформу не вырастет?
Пусть открывают. Хоть на FreeBSD будет нормальная ява.