Планы Sun по открытию Java

А где планы Microsoft по открытию .NET?

А разве сейчас исходники JavaCC и Hotspot JVM не доступны?

Можно сразу и на русский zdnet было давать. http://zdnet.ru/?ID=613087

А нахрена тогда вообще открывать, если не полностью?

> А разве сейчас исходники JavaCC и Hotspot JVM не доступны?

Доступны, но под CDDL, собираются же "открыть" под GPL.

Дык, микрософт же уже подарил миру .NET под GPL, ты разве не знал?

Писонул я как-то об этом в talks пару дней назад. Но факт радует!

> Дык, микрософт же уже подарил миру .NET под GPL, ты разве не знал?

Не под GPL, и не совсем дотнет, а всего лишь некая вещь с открытами исходниками для переманивания кодеров под unix-системы в мелкософт чтобы писать .net-framework

.NET - гомно. Моno должно сдохнуть.

Java - наше фсио, особенно, когда ее откроют.

> .NET - гомно. Моno должно сдохнуть.
> Java - наше фсио, особенно, когда ее откроют.

Да-да, Жаба вылезет из темных Сановских катакомб и подземелий и всех задушит :)

Не путайте Открытые Исходники (Open Source) и Свободное ПО (Free Software)!

Опять путают эти понятия.

Java давно открыта и имеет Открытые Исходники (read-only), но она НЕ Свободна (не read-write).

Лично мне наплевать на то, станет ли Java Свободной. Я не занимаюсь переделкой языка и системных библиотек, поставляемых с Java — это мисcия альтернативных проектов типа Apache Harmony. Но мне важны Открытые Исходники Java, и они ЕСТЬ.

---iZEN---

> Доступны, но под CDDL, собираются же "открыть" под GPL.

во-первых не под CDDL, а только для ознакомления

во-вторых если бы были под CDDL то GPL была бы не нужна, ибо CDDL имеет меньше ограничений, и признана как opensource

ну сколько можно насиловать этот труп?

Так что, можно будет вносить изменения в пакеты java.* и в язык? Сейчас, как я понимаю, даже посторонняя организация не имеет права реализовать JVM, не полностью соответствующую стандартам, или изменять/добавлять/удалять классы из пакетов *.java

anonymous (*) (18.08.2006 13:31:47)>Так что, можно будет вносить изменения в пакеты java.* и в язык? Сейчас, как я понимаю, даже посторонняя организация не имеет права реализовать JVM, не полностью соответствующую стандартам, или изменять/добавлять/удалять классы из пакетов *.java

А оно нам надо "вносить изменения"? Чтобы ещё больше было несовместимых форков? Java ценна своей стандартностью API и совместимости снизу вверх по версиям.

Код открыт по лицензии SCSL: http://java.sun.com/j2se/1.5.0/scsl/README-SCSL.html

> Java - наше фсио, особенно, когда ее откроют.

получил минуту назад при попытке посмотреть топик "Яндекс.Бар для Firefox":

500 Servlet Exception

java.lang.ClassNotFoundException: _view_22dmessage__jsp
	at com.caucho.util.DynamicClassLoader.loadClass(DynamicClassLoader.java:530)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:255)
	at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:315)
	at java.lang.Class.forName0(Native Method)
	at java.lang.Class.forName(Class.java:217)
	at com.caucho.util.CauchoSystem.loadClass(CauchoSystem.java:387)
	at com.caucho.jsp.JspManager.loadClass(JspManager.java:261)
	at com.caucho.jsp.JavaGenerator.compile(JavaGenerator.java:2836)
	at com.caucho.jsp.JspGenerator.generate(JspGenerator.java:322)
	at com.caucho.jsp.JspParser.parse(JspParser.java:327)
	at com.caucho.jsp.JspParser.parse(JspParser.java:232)
	at com.caucho.jsp.JspManager.createPage(JspManager.java:175)
	at com.caucho.jsp.PageManager.getPage(PageManager.java:346)
	at com.caucho.jsp.PageManager.getPage(PageManager.java:184)
	at com.caucho.jsp.QServlet.getPage(QServlet.java:220)
	at com.caucho.server.http.FilterChainPage.doFilter(FilterChainPage.java:129)
	at com.caucho.server.http.Invocation.service(Invocation.java:312)
	at com.caucho.server.http.CacheInvocation.service(CacheInvocation.java:135)
	at com.caucho.server.http.RunnerRequest.handleRequest(RunnerRequest.java:342)
	at com.caucho.server.http.RunnerRequest.handleConnection(RunnerRequest.java:272)
	at com.caucho.server.TcpConnection.run(TcpConnection.java:137)
	at java.lang.Thread.run(Thread.java:536)

Resin 2.1.6 (built Fri Nov 8 08:18:18 PST 2002)


так чо вы там говорили о жабе? ;)

И о чём это тебе сказало? По топику, абсолютно подерживаю открытие исходных кодов, хотя достать их можно было давно. И беспокоит факт если САН упустит монополию на внесение изменений в машину и апи.

Ну глядя на этот стектрейс, можно предположить что разработчики выложили не все файлы. Нужно просто проверить есть он или нет и если нет, добавить. Красивый и внятный вывод ошибки. Приятный язык.

я имел в виду, что жаба постоянно сыпется, особенно достали java.lang.ClassNotFoundException-ы, такое впечатление, что оно генерится каким-то рандомным генератором :) в основном из-за этого я в своё время и положил на жабу, и не обижусь, если она ответит мне взаимностью ;)

> Красивый и внятный вывод ошибки. Приятный язык.

ClassNotFoundException -- действительно, чего уж тут не понятного ;) приятно и красиво послал, даже тропинку описал куда идти надобно %)

Скорее это проблема не Java, а недостатка культуры разработки. К примеру у нас таких проблем не бывает, так как используется модульная система сборки (на основе maven). Ошибки в логах встречаются и много, но из-за нормального логирования, все они локализуются и исправляются быстро.

java.lang.ClassNotFoundException - это класс от Runtime Exception.

Обычно такие исключения пропускаются компилятором на этапе сборки, и дело в руках разработчиков прогнозировать их, перехватывать такие исключения, как и Checked Exceptions, тоже можно, но самому бросать их не имеет смысла, так как компилятор за ними не следит - опять же, самому разработчику надо следить за ними.

В данном контексте java.lang.ClassNotFoundException означает, что JSP-страница не смогла откомпилироваться в сервлет из-за каких-то проблем с преобразованием JSP->Servlet внутри контейнера. Продукт сырой, что ещё можно сказать? Трэйс стэка хорошая подсказка в том, где произошла ошибка.

---iZEN---

> Продукт сырой, что ещё можно сказать?

надеюсь, все поняли, что трейс выдал движок _этого_ форума? ;)

> так чо вы там говорили о жабе?

arsi, вы дурак? Когда у вас приложение на других крэшится, вы тоже самое про другие языки говорите?

--седайко стюмчик

> arsi, вы дурак?

и вам здрассе.

> Когда у вас приложение на других крэшится,

эм... только я не понял смысла фразы?

> вы тоже самое про другие языки говорите?

нет, только про те, на которых вылизывай-не вылизывай сорц, а сюрприз в виде анхендлед икзепшена все равно рано или позно получишь...

>я имел в виду, что жаба постоянно сыпется, особенно достали java.lang.ClassNotFoundException-ы, такое впечатление, что оно генерится каким-то рандомным генератором :) в основном из-за этого я в своё время и положил на жабу, и не обижусь, если она ответит мне взаимностью ;)

ClassNotFoundException - это тест на дурака. Если у программиста Java он регулярно появляется (да и вообще, если появляется) - это признак, что прог - дурак и ему настоятельно рекомендуется прекратить пытаться вести разработку на Java.

>нет, только про те, на которых вылизывай-не вылизывай сорц, а сюрприз в виде анхендлед икзепшена все равно рано или позно получишь...

О, истина. :) Лучше в С/С++ - там можно в коде воротить что хочешь, и никаких ошибок во время работы не увидишь - ни то, что по неинициализированному указателю записал, ни то, что вылез за границы массива (любое место хакеров для взлома - Array Overflow), да куча ситуаций, когда у тебя в программе отработала ошибка, а ты даже не подозреваешь, где.

А уж как хакерам приятно взламывать проги на С/С++....

> ClassNotFoundException - это тест на дурака. Если у программиста Java он регулярно появляется (да и вообще, если появляется) - это признак, что прог - дурак

ну зачем же такой резкий диагноз, просто элементарная несовместимость прог-язык. это как при переливании крови: то, что 3-й гпуппе нильзя перелить 1-ю, еще не значит, что 1-я (3-я) хреновая :)

> и ему настоятельно рекомендуется прекратить пытаться вести разработку на Java.

вот именно, мир так велик, соко в нем языков... ;)

> О, истина. :) Лучше в С/С++ - там можно в коде воротить что хочешь, и никаких ошибок во время работы не увидишь - ни то, что по неинициализированному указателю записал, ни то, что вылез за границы массива (любое место хакеров для взлома - Array Overflow), да куча ситуаций, когда у тебя в программе отработала ошибка, а ты даже не подозреваешь, где.

странно, а я зачем-то проверяю возможность помещения данных в массив, и зачем-то устанавливаю семафоры при удалении/перевыделении данных для указателя... глупо, правда? программеры на жабе и слов таких не слышали, и о выходе за границы массиваа не подозревают.. вот и сыпется у них рано или позно...

> А уж как хакерам приятно взламывать проги на С/С++....

в последнее время, хакерами называют себя те, кто способен изменить картинку при загрузке виндов... ну или хотя бы обои :) а хакеры, взламывающие С/С++ -- это бета-тестеры :)))

> А где планы Microsoft по открытию .NET? Ядро .NET с самого начало можно скачать. Rotor называется.

>Можно сразу и на русский zdnet было давать. http://zdnet.ru/?ID=613087

РУсский зднет тормозит. Просто эта новость 3 дня валялась в неподтвержденных.

>Сейчас, как я понимаю, даже посторонняя организация не имеет права реализовать JVM, не полностью соответствующую стандартам, или изменять/добавлять/удалять классы из пакетов *.java

Имеет. Спеки все доступны. Но пройти сертификацию ей не удастся и потому она не сможет называться Java Virtual Machine.

>Ну глядя на этот стектрейс, можно предположить что разработчики выложили не все файлы.

Я бы сказал что резина не смогла скомпилить JSPшку (по причине OutOfMemory завалился компилятор) но не сказал об этом Servlet Engine, и ClassLoader ожидающий что JSPха будет скомпилена очень удивлися этим стектрейсом что ее нет.

>странно, а я зачем-то проверяю возможность помещения данных в массив, и >зачем-то устанавливаю семафоры при удалении/перевыделении данных для >указателя... глупо, правда? программеры на жабе и слов таких не >слышали, и о выходе за границы массиваа не подозревают.. вот и сыпется >у них рано или позно...

Не... это только ТУПЫЕ программеры пихают synchronized в каждый метод... Зато потом ТУПАЯ java в большинстве случаев их убивает (lock elision), или наоборот обьединяет в один (lock coarsening), ну и еще кучу всякой фигни вытворяет... И ведь только полные mдаки перелопитили Java Memory Model, что б компилеру проще было оптимизировать lockи... А уж на кой фиг они в "тигре" всякие "atomic variables" и "nonblocking synchronization" выдумали - вААще загадка. И потом эти извращения с ConcurrentHashMap??? Ну на кой фиг нормальному человеку неблокированная запись аж сразу из 16 (по умолчанию) потоков???

> и о выходе за границы массиваа не подозревают...

Ну тут вообще отдельная песня. Я, как ТУПОЙ программер, предпочитаю словить эксепшн, чем когда у клиента прога зависает, а он (тоже ТУПОЙ), как на зло забыл поставить... VisualStudio??? Мне он етот эксепшн пошлет по мылу, а куда он пошлет Вас ето еще не известно... Кстати, если код "правильный", то есть hotspot может гарантировать, что никой магии с pointерами мы не делали - он проверку убьет, и будет мне счастие, а если я с индексом в высшею математику играю, то тут да... только пусть в нее разработчики API играют (ничего кстати против не имею - самому интересно бывает).

Спасибо.

да! это однозначно говорит о недостатках как языка, так и платформы!

равно как в очередной раз упавший nvu - о глубоких системных проблемах C++!

а может, все-таки, в обоих случаях как обычно - личные анатомические проблемы кодеров?

то есть, разница между "сыпется язык/компилятор/рантайм" и "сыпется прога", написанная на языке, решительно отсутствует?

iZEN, а как же Определение открытых исхоников?

Конечно, может я что не понимаю, но судя по всему изменение программы предполагается...

Проясните если что более знаете.

Хм, согласно Лоровким аннанимам-идеологам корпорции открывают только то, что уже сдохло.
Надеюсь это не так и жаба ещё поквакает :)

> Не путайте Открытые Исходники (Open Source) и Свободное ПО (Free Software)!

> Опять путают эти понятия.

> Java давно открыта и имеет Открытые Исходники (read-only), но она НЕ Свободна (не read-write).

Если тут кто-то что-то не понимает, так это ты, iZEN. Причём, совсем ничего не понимаешь.

Open Source и Free Software - технически (не политически) одно и тоже; читай определения, и список подпадающих лицензий. Таких понятий, как "read-only", "read-write" в данном вопросе нет; не надо нерелевантные термины выдумывать.

Sun Java - не Open Source, потому как распространяется под несвободной лицензией, которая совсем не Open Source.

>странно, а я зачем-то проверяю возможность помещения данных в массив, и зачем-то устанавливаю семафоры при удалении/перевыделении данных для указателя... глупо, правда? программеры на жабе и слов таких не слышали, и о выходе за границы массиваа не подозревают.. вот и сыпется у них рано или позно...

О, это да. :) Можно обойти проблему "записи по неинициализированному указателю", "записи вне границ массива" шаманскими танцами с бубнами на С/С+, только два вопроса - если все перепроверять в коде - 1. Быстродействие будет как у Джавы, ибо она медленней из-за этой кучи проверок, 2. Времени на написании убьется гораздо больше, а 90% программ время НАПИСАНИИ программы критичней времени РАБОТЫ программы. 3. И все равно, где-то да будет пропущенна данная ошибка, которая вылезет у клиента самым загадочным образом.

> О, это да. :) Можно обойти проблему "записи по неинициализированному указателю", "записи вне границ массива" шаманскими танцами с бубнами на С/С+,

это не "танцы с бубнами", а культура программирования, слышал о таком ;)

> только два вопроса -

не два, а три, и не вопроса, а утверждения :)

> если все перепроверять в коде - 1. Быстродействие будет как у Джавы, ибо она медленней из-за этой кучи проверок,

не совсем так. она медленней потому, что: а) байткод; б) выполняет массу ненужных вещей, где проверка на вхождение в рамки массива -- капля в море.

> 2. Времени на написании убьется гораздо больше, а 90% программ время НАПИСАНИИ программы критичней времени РАБОТЫ программы.

мы работаем на разных предприятиях. у нас как раз наоборот: программа должна занимать как можно меньше места (паять еще одну микруху памяти -- не вариант), работать максимально быстро в режиме реального времени, надежность 100% (никак не меньше).

а когда мне нужно за максимально короткие сроки написать прогу, не критическую к времени выполнения, я выбираю перл :)

> 3. И все равно, где-то да будет пропущенна данная ошибка, которая вылезет у клиента самым загадочным образом.

если ты не заметил, как раз это и произошло... с движком этого форума :) работал себе работал... и вылетел :)

>не совсем так. она медленней потому, что: а) байткод; б) выполняет массу ненужных вещей, где проверка на вхождение в рамки массива -- капля в море.

Байт-код сейчас на подавляющем числе платформ компилируется в момент запуска в нативный. А вот куча проверок на допустимость операции - это да, снижает скорость джаве в 2 раза по сравнению с С на аналогичном коде.

> А нахрена тогда вообще открывать, если не полностью?

В принципе, если только font-rendering engine будет закрыта, то её можно будет заменить на какую-то из существующих открытых. Впрочем, если Sun сглупит, и откроет код не под GPL, то форков не избежать всё равно (они уже сейчас есть).

Под форками я имел в виду реимплементацию Java.

> В принципе, если только font-rendering engine будет закрыта, то её можно будет заменить на какую-то из существующих открытых. Впрочем, если Sun сглупит, и откроет код не под GPL, то форков не избежать всё равно (они уже сейчас есть).

Хех, и сегодняшнюю ситуацию с надежностью будем вспоминать с глубокой тоской. ИМХО, предстоящее открытие - это полный писец для языка. Появится куча несоместимых, глючных и дырявых JRE, и как следствие сам язык станет синонимом глючности и дырявости.

Всё с точностью до наоборот. Надежнее, это когда на компе не установлена Java. Глючнее и дырявее, чем сейчас, Sun Java после открытия не будет. А выбрав правильную лицензию, число JRE только уменьшится.