Java RTS выбрана для управления радаром наблюдения за космосом

> Сразу два: StringBuffer и StringBuilder. Это так же как AWT и Swing по идеологии. :D

Ты ещё скажи, java.util.concurrent — набор костылей. У Java достаточно богатая стандартная библиотека, и это преимущество а не недостаток.

> Перегрузили бы оператор "+" для String, чтобы он не занимался перевыделением памяти под результирующую строку и всё в порядке было бы.

Блин, ты реально не понимаешь что ли? Как я тогда строку из класса буду возвращать? Понимаешь, у меня есть геттер, есть сеттер. Все изменения идут через сеттер, я их контролирую. Если я отдаю геттером, я знаю, что то, что я отдаю, никто не изменит. Если String будет мутабельным, класс вообще полагаться ни на что не сможет. Сразу делать public field-ы и не мучаться.

А с иммутабельными типами и расходом памяти нет никаких проблем вообще. Так устроен Java garbage collector. Он с иммутабельными типами работает просто превосходно.

> Нет никакой backward compatible — структуру .class файлов поменяли. Нельзя запустить код с -target1.5 на Java 1.4.2. > Для J2ME писать код с генериками невозможно.

Ну естественно. Имелась в виду, конечно же, совместимость на уровне исходников. Совместимость на уровне байткода никому не нужна.

> Вот для этого и изобрели Языки Высокого Уровня (ЯВУ). Сначала был изобретён FORTRAN, а потом Simula. Всё что раньше-позже уже не имело никакого смысла.

Fortran тоже неудобный язык. По настоящему удобные языки появились давно, вот только массово распространились лишь в последнее время, т.к. аппаратная платформа стала позволять. Всякие пайтоны и руби это ведь не изобретение 21 века, все эти идеи были ещё лет 30 назад.

>> Перегрузили бы оператор "+" для String

> Что я слышу? Правоверный жабобыдлокодеришко просит перегрузть оператор?!? Это же не кошерно!!!

Тупой аноним, оператор "+" для String и так перегружен — он занимается выделением памяти под новую строку (размер памяти — сумма от двух строк), копированием строк на новое место и пометкой ссылок на память двух исходных строк для учёта в GC.

Поэтому-то иммутабельность строк жрёт память как свинья помои. А быдлопрограммисты не знают об этой элементарной вещи, и потом вопят о памятежручести и тормознутости Java.

> После открытия (не изобретения даже) Лиспа уже ничего особо думать и не надо было.

Дурак! Думать нужно ВСЕГДА. Не надо делать из Java очередной диалект Lisp'а — в этом моя мысль. "Пусть расцветают сто цветов, пусть состязаются сто школ", — как сказал предводитель кетайцев.

> оператор "+" для String и так перегружен — он занимается выделением памяти под новую строку

оператор + реализован через StringBuilder. a + b === new StringBuilder(a).append(b).toString()

> Поэтому-то иммутабельность строк жрёт память как свинья помои.

Почитай про generational GC, ты наверное до сих пор думаешь, что GC это пометили корни, пометили всех потомков и удалили всё остальное.

>> Перегрузили бы оператор "+" для String, чтобы он не занимался перевыделением памяти под результирующую строку и всё в порядке было бы.

> Блин, ты реально не понимаешь что ли? Как я тогда строку из класса буду возвращать? Понимаешь, у меня есть геттер, есть сеттер. Все изменения идут через сеттер, я их контролирую. Если я отдаю геттером, я знаю, что то, что я отдаю, никто не изменит. Если String будет мутабельным, класс вообще полагаться ни на что не сможет. Сразу делать public field-ы и не мучаться.


Пля, ты тоже реально не понимаешь?
String должен перестать быть примитивным типом! Для этого он никак не подходит. Нужно менять дизайн языка в эту сторону.

> оператор "+" для String и так перегружен — он занимается выделением памяти под новую строку (размер памяти — сумма от двух строк), копированием строк на новое место и пометкой ссылок на память двух исходных строк для учёта в GC.

Или ты думаешь, что для мутабельной строки operator "+" будет вести себя по-другому? Если только строки будут на ropes сделаны, но это редко делают по ряду причин.

> оператор + реализован через StringBuilder. a + b === new StringBuilder(a).append(b).toString()

Чё ты мне суёшь фичку JVM 1.5? Это не поддерживается в Java 2.0, потому и несовместимо.

Java 5.0 и Java 2.0 это РАЗНЫЕ языки.

> String должен перестать быть примитивным типом! Для этого он никак не подходит. Нужно менять дизайн языка в эту сторону.

String это НЕ примитивный тип, это полноценный класс. java.lang.String. примитивный тип это int, double, ...

> Чё ты мне суёшь фичку JVM 1.5

В предыдущих версиях было, AFAIK то же самое, только вместо StringBuilder был StringBuffer.

> Java 5.0 и Java 2.0 это РАЗНЫЕ языки.

Никто вроде не утверждал, что они одинаковые.

> Java 5.0 и Java 2.0 это РАЗНЫЕ языки.

Да 2.0 уже давно не уперлась никому, у всех вендоров уже 6.0 jvm выпущены в продакшен. Собственно, только после 5.0 Java стала хорошим языком. Аннотации, дженерики - они прекрасны. Они радуют!

Только вот лямбды не хватает, да. Но все к тому идет.

> В предыдущих версиях было, AFAIK то же самое, только вместо StringBuilder был StringBuffer.

Нет. J2ME заявляет совместимость по формату файлов с Java 1.4 (Java 2.0). Мидлеты с простой конкатенацией строк оператором "+" жрут память только так.

> Аннотации, дженерики - они прекрасны. Они радуют!

Первая доза бесплатно.

А кто тебя, кретина, заставляет такой конкатенацией пользоваться?

В РФ даже есть люди, видевшие эту hard-RT JVM своими глазами: http://www.sql.ru/forum/actualthread.aspx?tid=533715&pg=3#5544477

Для true: Но мне их уже на СанТехнических днях рассказали немного.

> Другое дело - реал-таймовость.

Там же демонстрировали hard-RT jvm. Платная. Поверх солярки или SUSELinux/RHEL + спец ядро.

> Нет. J2ME заявляет совместимость по формату файлов с Java 1.4 (Java 2.0). Мидлеты с простой конкатенацией строк оператором "+" жрут память только так.

Понятия не имею, что там с мидлетами и какая там виртуальная машина. Естественно, если в цикле конкатенировать строки оператором +, то это в морг. С этим вроде тоже никто не спорит. В чём собственно разногласие то?

>> даеш эксплоиты под телескопы! научим жалких людишек программировать!

> Новое слово в науке? Эксплоит на Java?

На случай, если ты не знаешь: в real-time Java возможно обращение к физической памяти в обход ОС.

> в real-time Java возможно обращение к физической памяти в обход ОС.

Из байт-кода или из подгружаемой библиотеки на C?

В смысле поддержки его на уровне виртуальной машины - таки примитивный (ldc и подобные инструкции), да и в языке тоже, поскольку есть специальный синтаксис для литерала.

>> в real-time Java возможно обращение к физической памяти в обход ОС.

> Из байт-кода или из подгружаемой библиотеки на C?

Точно не знаю, Какая разница, откуда именно?

Просто интересно. В плане того, что в джаве можно делать песочницы и прочее. В общем понятно, не знал.

Хм... Что тут можно "не знать"? Наличие JNI само по себе гарантирует такие возможности.

Собственно, одна из первых ссылок в гугле: http://www.onjava.com/pub/a/onjava/2006/05/10/real-time-java-introduction.htm...

"Java RTS allows direct access to physical memory, making it similar to J2ME. No surprise there: one of the main target platforms of real-time Java is embedded systems. This means that now you can create device drivers written in pure Java. Although memory access is not directly a real-time issue, physical memory access is desirable for many applications. Java RTS defines a new class that allows programmers byte-level access to physical memory, as well as a class that allows the construction of objects in physical memory."

Там потом идет блабла про "Java maintains strong security protections by controlling memory bounds and data contents", но /me не понимает, как они этого добьются.

Обходить защиту памяти?

> /me не понимает, как они этого добьются.

При JIT-компиляции этой хитрой инструкции вставляют проверки видимо. Хотя не буду фантазировать.

>>> даеш эксплоиты под телескопы! научим жалких людишек программировать!

>> Новое слово в науке? Эксплоит на Java?

>На случай, если ты не знаешь: в real-time Java возможно обращение к физической памяти в обход ОС.

Спецификация RTSJ у меня есть, ничего такого я там не нашел. Работать без GC можно, к физической памяти обращаться нельзя.

Интересно какой способ ухода из жизни выберет радар ?

>> в real-time Java возможно обращение к физической памяти в обход ОС.

> Спецификация RTSJ у меня есть, ничего такого я там не нашел.

.oO( почему меня это не удивляет? )

http://java.sun.com/javase/technologies/realtime/

Тебя я уже нарисавал ;) http://lexxlinux.blogspot.com/2008/04/blender-bender-and-beer.html

> Естественно, если в цикле конкатенировать строки оператором +, то это в морг.

Это да. Но это же неправильно!

> С этим вроде тоже никто не спорит.

Я с этим спорю.
Если есть первоначальная идея использовать оператор "+" для конкатенации строк, то зачем нужны другие костыли? В этом аспекте мне не нравится "улучшения" Java.

Пошукай тут http://www.codecommit.com/blog/scala/quick-explanation-of-scalas-syntax, и не такие за..ы найдешь. И все это на JVM. Так что твой C# уже по факту догоняющий. Если уж очень хочется delegate TReturn SelfApplicable<TReturn>(SelfApplicable<TReturn> self);

SelfApplicable<Func<Func<Func<int, int>, Func<int, int>>, Func<int, int>>> YC = y => f => x => f(y(y)(f))(x); то на JVM это все можно получить, взяв компилятор scalac. Правда, как в таком спагетти-коде можно что либо понять, и что этот код делает^Wкакую задачу он решает, уму нерастяжимо. Это напоминает ветку, где также сишарпника мокали в г...о http://community.livejournal.com/ru_java/630745.html

> Интересно какой способ ухода из жизни выберет радар ?

Радар поймает метеорит. :D

И какие недостатки это помогло бы побороть|решить? Серьезно, какие?

Почитайте Эккеля, он уже заткнул свой хайп по поводу Руби и вернулся на Землю, предлагает отказаться в следующей версии жабы от обратной совместимости с 1.1, 1.2, 1.4 etc. И предлагает сделать сразу Java 3000, хехе. http://www.artima.com/weblogs/viewpost.jsp?thread=227728 Ну, в каментах там как и на ЛОРе, насрали негатива, так что их можно не читать

>Ещё один недочеловек, не понимающий комбинатора фиксированной точки? ЛОР полон ничтожеств!

Ты понимаешь, в чем соль, я как бы не хочу в секретном ящике писать для оборонки комбинаторы фиксированной точки на хацкеле, php, C# или lisp за еду. Я более сложные вещи в ВУЗе проходил, такие как сопромат, гидродинамика, теории волн и дифракции, теормех, так что когда увижу вакансии требующие знания "комбинатора фиксированной точки" за многобабла, разберусь с ней за пару месяцев. Ты такие вакансии сначала какбы покажи.

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

Нет, а причем тут это и мутабельный String? Ты как бы не рассказал, какие проблемы мутабельность стринга решит, и сколько при этом создаст ? String же не просто от балды сделали immutable http://www.javafaq.nu/java-article1060.html Хочешь, чтобы жаба стала вторым дырявым php?

это не моё
http://bp2.blogger.com/_HwMmgrNNcFw/R_9jh6HmJ-I/AAAAAAAAAE4/ACFJ7oCK3ig/s1600...
а какой то ужис, или ранняя поделка профессора
выложи исходники, я хочу с заливками разобраться и скелетами

> Так кто нибудь может нормально объяснить, как java обеспечивает эти 20 мкс, если ядро самой ОС, под которой эта java ходит, не всегда такое может.

Вероятно, там специальное ядро. Не зря же Мольнар работает на RedHat.

> я как бы не хочу в секретном ящике писать для оборонки комбинаторы фиксированной точки на хацкеле, php, C# или lisp

Тебе и не придется. Даже если ты решишь таки поработать там.

>> А как же StringBuffer? Уже плохой?

>Он потокобезопасный, и, соответственно, имеет накладные расходы, которые в большинстве случаев не нужны.

А StringBuilder?

>Хаскелист бы тебе сказал: да, не нужны. Я скажу, что нужны, но совсем не так часто, как это кажется. Я например был бы рад, если бы по умолчанию все переменные были final, и делались mutable принудительно. Это значительно увеличило бы простор компилятора для оптимизаций, в том числе и для автоматического распараллеливания кода, которое всё актуальней с каждым годом.

Устарело. В Java 6.0 объявление всех мемберов final названо порочной практикой, мешающей комплятору эффективно оптимизировать. Где я это читал, уже не помню

Писцы пришли посццссмортереть на радар )))

Что-то мне подсказывает, что русское слово "радар" (синоним РЛС) здесь весьма неуместно, а вот "радиотелескоп" - в самый раз.

Ср. "radar" vs "радар" на википедии.

>Тебе и не придется. Даже если ты решишь таки поработать там.

Бугога. Уныло. Знаешь, есиб в ящике платили хотя б 20 тонн RUR, я б там работал и еще тебе бы, программеру, задачи ставил.

Ссылку, интересно. Мешать компилятору это уж точно не может, помогать обычно тоже, т.к. он способен увидеть, кто мутабельный а кто нет, если member private. Писать final-ы везде получается банально нечитабельный код.

Я вообще фигню написал, тут скорее поинт в том, что константность по умолчанию изменила бы сам стиль написания кода.

>Перегрузили бы оператор "+" для String, чтобы он не занимался перевыделением памяти под результирующую строку и всё в порядке было бы.

Скажи, а как JVM добавит память к String, если после String она уже занята другими объектами? Только выделив НОВЫЙ кусок в конце свободной области. Так какая мне нах разница как программисту, как записать эту операцию, если в железе она будет выполнена одинаково? Увеличить размер массива можно только выделив память под НОВЫЙ массив большего размера. Или ты думаешь коллекции в Collection растут магическим образом, а внутри в них не массивы, хехе?

>Нет никакой backward compatible — структуру .class файлов поменяли. Нельзя запустить код с -target1.5 на Java 1.4.2.

А это точно из-за generic-ов? А не из-за Enum-ов?

> Бугога. Уныло.

Всегда думал, что пересечение этих двух понятие есть пустое множество. Сегодня анонимус с ЛОРа наглядно опроверг это расхожее мнение... "Маша не дура? Бугога, уныло." (C)

>> Тебе и не придется. Даже если ты решишь таки поработать там.

> Бугога.

Смех без причины...

> Знаешь, есиб в ящике платили хотя б 20 тонн RUR

В ящиках, которые я знаю, столько платят.

> я б там работал

Нет. Иначе ты бы _уже_ работал там.

> и еще тебе бы, программеру, задачи ставил.

Возможно. А кто-то ставил бы задачи тебе.

> Правда, как в таком спагетти-коде можно что либо понять, и что этот код делает

Быдло не поймет. Быдло не нужно. Любой математик поймёт сразу.

> Ты понимаешь, в чем соль, я как бы не хочу в секретном ящике писать для оборонки комбинаторы фиксированной точки на хацкеле, php, C# или lisp за еду.

Оборонка этим и не занимается, быдлокодеришко. Так что за еду кодеришь ты в своей быдлятне.

> Ты такие вакансии сначала какбы покажи.

Ну, ты жалкий нищеброд, что с тебя взять. Бегаешь по вакансийкам в газетёнках "работа для вас"... Типичный бздёжь быдлокодера от тебя исходит, ничего нового. Тебя никто и близко не подпустит туда, где пишут действительно дорогостоящие, сложные, серьёзные вещи - к финансовой математике, например, к CAD-ам, к AI (САПРам), и т.п. Потому и доходы у таких как я в десятки раз выше чем у таких, как ты.

> есиб в ящике платили хотя б 20 тонн RUR

Ну я и говорю, нищеброд.

>В смысле поддержки его на уровне виртуальной машины - таки примитивный (ldc и подобные инструкции), да и в языке тоже, поскольку есть специальный синтаксис для литерала.

Угу, как только специальный синтаксис для литерала уберут, радетели простоты и уанлайнеров потребуют ввести новый специальный синтаксис в новой версии.

Не пойму, а кто мешает не пользоваться String, а тасовать чары прямиком в Array()? Или без toUpperCase() и прочих ну никак не обойтись?

>Ссылку, интересно. Мешать компилятору это уж точно не может, помогать обычно тоже, т.к. он способен увидеть, кто мутабельный а кто нет, если member private. Писать final-ы везде получается банально нечитабельный код.

>Я вообще фигню написал, тут скорее поинт в том, что константность по умолчанию изменила бы сам стиль написания кода.

Не помню, в одной из многочисленных статей сравнения C# 2.0 и Java 5.0, типа "а вот в шарпе у Хельсберга все final и поэтому компилируется оптимальнее, а в жабе надо каждый раз писать final", на что-то кто-то где-то в блоге ответил мол final рекомендовалось писать до 1.4 включительно, а начиная с пятой это если и не мешает, то и не помогает компилятору оптимизировать, он уже сам все где надо инлайнит и финалит в ЖИТе. Ссылку вряд ли найду