Джеймс Гослинг, «Отец» Java, уволился из Oracle

Она выделяет память под новый объект но не копирует массив с данными. Что тут оптимизировать?

Здесь — ничего.

А в fully-мутабельных строках можно было бы, к примеру, поменять один из символов строки простой командой s.changeCharAt('Ъ', 10);.

А сейчас приходится прибегать к костылям для выделения подстрок в исходной строке и конкатенации их символов с нашим 'Ъ' посредством явного вызова костыля StringBuffer/StringBuilder. Умно?

> Вас это беспокоит?

Очень.

Инфраструктура для поддержки операций над String довольно большая, чтобы умещаться во встраиваемых (читай — микроскопических) устройствах «размером» с RFID.

Их бы убивало очередное пришествие пророка OutOfMemoryException на землю, но только если бог не успевал бы добавить памяти.

Из Бездны появится быстрее java.lang.StackOverflowError, чем Бог успеет добавить памяти. :))

Атвичайу : )

большую часть отжирает приёмник с передатчиком, потом экран, потом процессор, там java нет ни разу

Дурашка, Java — это не домовёнок и не леший, она сама по себе ничего не отжирает. Зато вот когда вся эта монструозная машина начинает терзать процессор на максимальной частоте и нагрузке, вот тут-то вы и насладитесь зрелищем садящейся за два-три часа батарейки. В то время как (я про сименсы сейчас говорю) нативно написанные приложения вообще не загружают процессор => батарейка держит столько, сколько положено (около суток-двух) => профит.

постоянно с кривыми прошивками, детскими багами и прочими весёлостями

Так речь-то не об официальных прошивках от изготовителя. Проснитесь.

на тот момент она была вполне нормальная, сейчас - УГ полное, Вы отстали от жизни

Как полноправный анон заявляю — имею в распоряжении Siemens EL71 и iPhone 3G. Сравним юзабилити. Сименс маленький и аккуратный, айфон лопатозный, но это мелочь. И тот и другой аккум держат сутки. На сименсе присутствует многозадачность, на айфоне — нет. На сименсе есть удобные сворачиваемые IM-клиенты и можно печатать вслепую, на айфоне — нет. На сименсе есть нативный клиент для серверов Opera Mobile, на айфоне даже в зоне покрытия тремя же грузится всё невероятно медленно (скорость больше, но объёмы загрузки больше непропорционально, и без всякого сжатия трафика). Ну и наконец, на сименсе есть фонарик. А камера в нем чуть ли не лучше, чем в айфоне, и может видео даже без джейлбрейка. Я согласен, что айфон — говно пример, именно трубка для понта. Но все остальные трубки выглядят так же. И кстати, сименс я могу купить новый за две тысячи рублей. Покажите мне удобный не жрущий аккум смартфон с удобной многозадачностью, который стоил бы хотя бы пять тысяч. И я молчу про трафик, потребляемый новыми аппаратами. Хо! Хо! Хо!

>А в fully-мутабельных строках можно было бы, к примеру, поменять один из символов строки простой командой s.changeCharAt('Ъ', 10);.

Так в чем проблема то - используй и храни StringBuilderа. Преобразование их в String (где интерфейс требует) опять же за константу.

белко, ты и на березу влезло :-) demotivation.ru/3nqol97xswftpic.html

Куда засовывать новость о том, что Google финансирует разработчиков порта кодека Theora на ARM устройства?
http://arstechnica.com/open-source/news/2010/04/google-boosts-open-video-by-f...

Отвечу, пожалуй, сразу нескольким.

Пробовали на Си писать? Там в голове столько всего надо держать, чтобы написать какую-то более или менее сложную программу. Зато те, кто хоть раз писал на ассемблере могут понять насколько эффективно будет работать приложение. Однако написание программ на Си очень трудоёмко и требует высооплачиваемых программистов. К тому же время разработки приложение будет больше, чем для высокоуровневых языков. Так зачем корпорациям заморачиваться с выпуском оптимизированных программ. Куда проще использоваться Java, .Net. Обучить писать на этих платформах куда проще, чем на Си. Ну а пользователь? Ну прикупит дполнительно памяти, поставить более быстродействующий процессор. Благо это сейчас возможно ибо далеко не 90-годы 20 века.

Сюрприз! И на C, и на Assembler (даже приходилось вручную машинные коды вводить), и на нескольких десятках других языков.

И пока что замечаю следующее:

* быстрый софт можно писать почти на любом языке, но некоторые вещи требуют ассемблер или C

* Java или C# пользоваться не намного проще чем C. Накодить кала можно легко, не спорю. Но приличный софт большинство создать не может. C'est la vie. Сила Java и C# в том, что они обеспечивают больше гарантий касательно поведения софта при незначительном отставании в скорости. Причем для фанатов реактивной тяги есть возможность вызывать код на C.

IMHO идеальный вариант для многих крупных программ: почти все на высокоуровневом языке и немного хорошо вылизанного кода на C там, где без него действительно не обойтись.

Реальная проблема явы не в производительности, с ней всё боле-мене, а в работе с памятью.

Сказал, как отрезал. Конечно, она не идеальна, но есть широкоизвестный факт, что в подавляющем большинстве случаев языки с GC рвут те, что без GC, на мелкие ошметки. Хотя бы в силу штук вроде heap compaction.

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

Согласен. Это еще один возможный повод.

утечки памяти из-за метода finalize

Можно поподробнее? Кто и зачем использует finalize и как именно получается утечка памяти?

странные checked исключения, которые зачем-то надо постоянно упоминать в throws

Это, конечно, вопрос религии. Предполагаемая (и мной ценимая) польза в том, что сразу ясно, какие исключения могут возникнут при вызове метода. В отличии от всякой порноты вроде плюсов, где любая Годзилла может вылезти даже в itoa. :)

невозможность определения операций

Ну, может кому и мешает. :) Если операции не переопределять, то может и будет с этого профит. В Хаскелле этого пруд пруди, и ничего. Удобно. Но обратно же, это не killer feature.

невозможность автоматичекого освобождения ресурсов при завершении контекста (в 7-ке появится - но возможно опять будет не то, что нужно)

А можно поподробнее? Что за контекст и что за ресурсы?

странный, пожирающий память, класс String, с методом substring, который держит ссылку на оригинальную строку.

Он не странный, а экономный. Просто надо знать, как он работает. Предположим, у Вас есть стока в N символов и вам надо разделить ее на две половины, поменять их местами и соединить. В случае нынешней реализации подстроки съедят совсем немного: указатель на изначальный массив буковок, длины и смещения. Далее собирается строка-результат. При большом N будет скопированно (грубо) N байт. Если подстроки бы хранили свои собственные фрагменты, то было бы скопировано 2N байт. Кстати, не только в Java такая реализация. А утечек памяти с ней нет. Просто если Вам надо где-то долго хранить маленький фрагмент большой строки, то надо явным образом снять с него копию.

это юзается package-конструктор, который данные не копирует.

Да, не копирует. А зачем? Достаточно переназначить указатели на начало и конец подстроки в исходной строке, а потом, если потребуется, применить костыли, чтобы сделать иммутабельную версию и отдать её юзеру.

Вперед и с песней. Вот у тебя одна строка. С твоим подходом можно надругаться над ней с сделать из нее подстроку. А что делать, если надо несколько подстрок одной строки? Нус, мудрейший..?

> А теперь представь, какой производительности и насколько низких затрат ресурсов можно было бы добиться, будь ведроидные приложения не на жаве, а на С, например!

Фигня в том, что компании дешевле написать программу под Андроид на java, а не на С. И даже больше дешевле писать на Java, а не на С. потому и клепаются пачками программы да приблуды корпоративные.

И вряд ли MeeGo сможет догнать по популярности Андроид именно в силу того, что С, а не Java является базовым языком.

> Кластер нужен в одном из двух случаев:

1. нужно молотить большие объемы данных (и тут уж любой язык не сможет существенно улучшить ситуацию)

2. разработчики - дауны (наиболее вероятная причина)

Еще один случай вы забыли - защита работы приложения от сбоя железа. Только через кластер или иной способ «кластеризации вручную» приложения.

> Пожалуйста, не надо про яву на андроидах - безбожный тормоз.

Толсто ;)

PS владелец Андроидо-фона.

> утечки памяти из-за метода finalize

Это как вы получили такое?

equals и ==

забавная шутка создателей языка. дело привычки в общем ;)

странные checked исключения, которые зачем-то надо постоянно упоминать в throws

чтобы потребитель вашей либы знал ЧТО КОНКРЕТНО может вылететь из вашего класса и обработал это. Хотя согласен холиворная темя checked exceptions.

невозможность определения операций

не реализовано ввиду наличия большого кол-ва неявных косяков. также как и множественное наследование.

Generics 1.6 с одной стороны принесли легкое облегчение - с другой нарушили совместимость с Java 1.4 и поэтому принесли страдания. Также generics не совсем то, что нужно - так как вся эта информация имеется только в момент компиляции, и при выполнении отсутствует.

type erasyre это конечно косяк. но какую совместимость нарушили с 1.4? разве код из 1.4 не скомпилится под 1.6?

В java 1.6 добавили новый класс StringBuilder и метод String.format (аналог printf) — но не сделали бэкпорт в Java 1.4.

1.4 уже давно закопана. наверное и 5.0 стоит отправить в историю. 6-ка же давно как в продакшене обкатана.

> А в fully-мутабельных строках можно было бы, к примеру, поменять один из символов строки простой командой s.changeCharAt('Ъ', 10);.

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

> По моему опыту, у Java тормозит все, что имеет графический интерфейс ...

Кстати, довольно верное замечание. Внутренности Swing'а таковы, что используется очень мало аппаратной акселерации, и практически все элементы интерфейса реализованы на самой же яве, и им не зазорно рисоваться хоть поточечно. Swing оставляет двоякое впечатление: мощно и гибко, но out-of-box только стандартные контролы, что-то нестандартное, и пиши свой код, есть переносимость, но нет использования уже ускоренных реализаций элементов из OS. Я игру писал на Swing'е, было терпимо, но непредсказуемые моменты сборки мусора иногда конкретно мешали гладкости интерфейса.

> А в fully-мутабельных строках можно было бы, к примеру, поменять один из символов строки простой командой s.changeCharAt('Ъ', 10);.

Изень, тебя, похоже, обделили разумом. Ты не представляешь, сколько проблем мутабельность создаёт в С++ строках в мультитредовых приложениях. Путь, который выбрала ява со строками — очень оправдан.

> Предполагаемая (и мной ценимая) польза в том, что сразу ясно, какие исключения могут возникнут при вызове метода. В отличии от всякой порноты вроде плюсов, где любая Годзилла может вылезти даже в itoa. :)

А в яве любой RuntimeException. И за что боролись?

> Сказал, как отрезал. Конечно, она не идеальна, но есть широкоизвестный факт, что в подавляющем большинстве случаев языки с GC рвут те, что без GC, на мелкие ошметки. Хотя бы в силу штук вроде heap compaction.

«Мы университетов не кончали», что наблюдаю, то пою. GC чем-то хорош, чем-то отличен, но не только в нём дело. JIT хапает память, при том впрок, я так понимаю. GC включается во время анимации/звуковых эффектов на Swing - ваще не айс.

Это ясно даже и ежу. Но надо же побрызгать слюной.

> Лучше бы String сделали мутабельным

Лучше довели бы до ума что-нибудь наподобии интерфейса CharSequence и начали бы использовать в вызове стандартных библиотек. К сожалению текущая реализация CharSequence не годится из-за наличия метода toString. Ведь и сейчас не сложно написать нормальную реализизацию строки, но все равно все закончится вызовом toString() и превращением объекта в строку с последующей передачей в какую-нибудь библиотечную функцию.

Да и с мутабельностью было бы не плохо что-нибудь сделать наподобии модификатора const из C++. Если я передаю объект в качестве аргумента, то я не знаю что с ним случится - будет он модифицироваться или нет. То есть только для того, чтобы гарантировать, что объект модифицироваться не будет - мне придется сделать отдельный специальный read-only объект копию и передать ее в качестве аргумента.

Невозможность вернуть более одного значения и невозможность определения output параметров, приводит к тому, что приходится возвращать объекты через аргументы Holderы. Для получения output параметра создаем в куче дополнительный объект.

Java не поддерживает inline включения объектов. Почему нельзя понять на этапе компиляции (я даже согласен дать указание компилятору в виде ключевого слова inline), что я будут использовать конкретную реализацию класса и хранить содержимое объекта, а не ссылку на него. А что имеем сейчас - куча объектов это просто какой-то мешок с червями. Наш красивый объект с несколькими полями объектами раскидывается по всей системе - отдельно объект со ссылками - отдельно объекты с содержимым полей, которые в свою очередь дальше раскидываются по куче. Причем при выделении каждого объекта имеются накладные расходы - получаем расход памяти.

Я уж молчу про невозможность выделения объектов на стэке. Все объекты выделяются в куче - хотя вроде есть какие-то подвижки в виде escape analysis и выделение объектов в стеке и даже в виде использования регистров для хранения объектов.

И постоянно как мантра повторяется - сборщик мусора, сборщик мусора, сборщик мусора..... Причем этих сборщиков несколько mark&sweep, generational, G1, но легче от этого не становится. Что особенно добивает со сборщиками мусора под windows - это насильное вытеснение кучи объектов в swap. Получается примерно так: минимизировал приложение на Java -> через какое-то время вся куча объектов вытеснена в swap, и когда снова открываешь приложение чтобы продолжить работу вдруг великий и ужасный сборщик мусора желает убрать мусор. Только вот проблема заключается в том, что весь мусор в swap на диске и прежде чем его убрать его надо прочитать, в результате получаем феерические тормоза. Народ, конечно, решает проблему путем насильственного вызова сборщика мусора при минимизации приложения, но все равно это не является полноценным решением.

Вижу огромное преимущество Java только в одном - возможность подключения почти к любой базе данных через JDBC.

>> утечки памяти из-за метода finalize

Это как вы получили такое?

Легко - если метод finalize бросает исключение - то gc его больше собирать не будет. Утечка памяти возникла в драйвере jdbc - пришлось декомпилировать и патчить.

1.4 уже давно закопана. наверное и 5.0 стоит отправить в историю. 6-ка же давно как в продакшене обкатана.

Нет - не закопана. Причем особенно смешно было, кода после установки java 1.6.0.17 отваливался java web start для java 1.4

> В языке и компиляторе, последний любую конкатенацию строк заменяет вызовами StringBuffer/StringBuilder.

Да это поражает. Причем жестко сделали операции сложения для строк, но не сделали такого же для BigDecimal. Кто мешал сделать такой же хак для BigDecimal?

Что-то про MySQL вспомнил... никто не знает, Oracle с ним еще ничего не сделала?

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

E63 с qwerty за 7 тыщ

>> А в fully-мутабельных строках можно было бы, к примеру, поменять один из символов строки простой командой s.changeCharAt('Ъ', 10);.

Так в чем проблема то - используй и храни StringBuilderа. Преобразование их в String (где интерфейс требует) опять же за константу.

Ты за тредом обсуждения совсем не следишь что ли?

Основная моя мысль была о том, что те, кто хочет использовать мутабельные строки, так делают — используют StringBuffer/StringBuilder. Но они это делают не из-за отсутсвия альтернативы, а из-за изначально кривой архитектуры стандартной библиотеки.

В классе String можно инкапсулировать поведение StringBuffer/StringBuilder и гибкое распределение памяти (кэш символьных последовательностей), но этого не сделали.

> Гослинг написал свой Емакс

И свои иксы тоже.

>> странные checked исключения, которые зачем-то надо постоянно упоминать в throws

чтобы потребитель вашей либы знал ЧТО КОНКРЕТНО может вылететь из вашего класса и обработал это. Хотя согласен холиворная темя checked exceptions.

К сожалению корректность checked exceptions гарантирует компилятор java sun. На уровне jvm уже нет никаких гарантий - можно бросить любое исключение (в том числе и checked exception) независимо от того, что указано в throws.

Я изобрел для себя два следующих способа более-менее корректной борьбы с checked exceptions

1. Добавляем к методу throws Exception

или

2. catch(Exception ex) { throw new RuntimeException(ex) }

>> Пожалуйста, не надо про яву на андроидах - безбожный тормоз.

Толсто ;)

PS владелец Андроидо-фона.

Эээ, как-бы 3D игры под Андроид нынче пишут на С++, потому как на яве - тормозит. Я очень надеюсь, что в скором времени это досадное недоразумение исправят. 2.0 уже содержит JIT, по-умолчанию отключенный. Есть надежда, что к 2.1 допилят.

>Java не поддерживает inline включения объектов. Почему нельзя понять на этапе компиляции (я даже согласен дать указание компилятору в виде ключевого слова inline), что я будут использовать конкретную реализацию класса и хранить содержимое объекта, а не ссылку на него.

Это делает среда исполнения. В число оптимизаций, которые HotSpot VM осуществляет над «горячими» участками кода (выполнение которых занимает много времени) входит также и inline.

Да, не копирует. А зачем? Достаточно переназначить указатели на начало и конец подстроки в исходной строке, а потом, если потребуется, применить костыли, чтобы сделать иммутабельную версию и отдать её юзеру.

Вперед и с песней. Вот у тебя одна строка. С твоим подходом можно надругаться над ней с сделать из нее подстроку. А что делать, если надо несколько подстрок одной строки? Нус, мудрейший..?

Список последовательностей символов, а не «начало» и «длину», как это сделано в java.lang.String:

    /** The offset is the first index of the storage that is used. */
    private final int offset;

    /** The count is the number of characters in the String. */
    private final int count;

> type erasyre это конечно косяк. но какую совместимость нарушили с 1.4? разве код из 1.4 не скомпилится под 1.6?

Обратную совместимость - код написанный под 1.6 становится потерянным для 1.4. Разработчиков библиотек принуждают или игнорировать 1.6 или поддерживать несколько версий библиотек.

Да брось ты эту джаву вообще.

> входит также и inline.

только inline методов.

inline объектов - это совсем другое.

Ну например мы объявили класс Complex { double re; double im; }

и при определении поля inline private Complex a;

при компиляции получим два поля private double re; private double im;

> Да брось ты эту джаву вообще

Не могу - она меня кормит и поит ;)

Уволься, картошку на ферме расти и продавай, о вечном думай.

> А можно поподробнее? Что за контекст и что за ресурсы?

Можно в презентациях Java 7 посмотреть. Будет некий аналог .Net оператора using.

Просто если Вам надо где-то долго хранить маленький фрагмент большой строки, то надо явным образом снять с него копию.

А если я не знаю какую строку я получил? Например я читаю поток и разбираю его XML парсером. В какой-то момент я получаю строку - пусть это будет значение атрибута. И что мне с этой строкой делать? Это какая строка - маленькая или она содержит указатель на огромноый массив символов? И получается, чтобы гарантировать, что у меня не будут где-то болтаться фрагменты исходного потока, я строку скопирую. При этом, если она уже была скопирована, то я создаю дополнительную нагрузку на gc. Но это лучше, чем огромный бессмысленный беспощадный расход памяти.

В общем, не сложилось у тебя с эксепшенами.

> при компиляции получим два поля private double re; private double im;

интересно, это то же самое, что си-шарповские структуры, или нет?

З.Ы. отсюда кстати видно, почему в яве плодят геттеры-сеттеры — геттер для поля а будет делать его копию, чтобы случайно не поменять само поле в структуре.

s/само поле в структуре/само поле в объекте/

> Уволься, картошку на ферме расти и продавай, о вечном думай.

Сначала сам уволься, картошку на ферме расти и продавай, только потом советуй это на ЛОРе.

> inline объектов

с первого взгляда кажется, что инлайн объектов мощнее чем шарповые структуры, но с другой стороны возникает сомнение — а будут ли где-то нужны объекты, которые требуются как заинлайнеными, так *и* не заинлайнеными?

ведь скорее всего будут требоваться *либо* всегда-заинлайненные-объекты (с семантикой значения и копированием), либо никогда-не-заинлайненнные (обычные ява объекты), не?

vozmi nokia e72 i ne parsya, u menya postoyanno Fringe(Gmail,Skype) vklyuchen chasov po 10 v sutki, muziku slushayu , emails proveryautsya kazhdie 5 minut. zaryazhayu 1-2 raza v nedelyu, i vse kak ya ponimayu na Java (Simbian)

Не, копии не будет, если только сам программист не озаботится клонированием возвращаемого объекта.

> Будет некий аналог .Net оператора using.

Ой, а в яве и этого не было? А я думал я доку недочитал....

А представители Oracle на Sun Tech Days объявили что его не будет уже только на лекции где он должен был выступать, притом сказали что это «чисто транспортная проблема».

В общем не доверяю я Oracle теперь - больно нагло наврали.

>>> Да, не копирует. А зачем? Достаточно переназначить указатели на начало и конец подстроки в исходной строке, а потом, если потребуется, применить костыли, чтобы сделать иммутабельную версию и отдать её юзеру.

Вперед и с песней. Вот у тебя одна строка. С твоим подходом можно надругаться над ней с сделать из нее подстроку. А что делать, если надо несколько подстрок одной строки? Нус, мудрейший..?

Список последовательностей символов, а не «начало» и «длину», как это сделано в java.lang.String:

1. мое замечание справедливо независимо от реализации строк. Можешь их хоть на кубитах их сделать. Если они мутабельны - проблема есть. Не согласен - предъяви пример, как из одной мутабельной строки мы выдираем подпоследовательности 1-4 и 7-9 и соединяем их вместе. Язык/библиотека могут быть любыми. :)

2. суть предлагаемой реализации не уловил. Можно поподробнее и с обоснованием, что оно не будет тормозом?

Инфраструктура для поддержки операций над String довольно большая, чтобы умещаться во встраиваемых (читай — микроскопических) устройствах «размером» с RFID.

Я правильно понимаю, что на RFID мощная поддержка строк нужна для реализации СУБД? ;-) Или есть другие, архинужные применения?

А можно поподробнее? Что за контекст и что за ресурсы?

Можно в презентациях Java 7 посмотреть. Будет некий аналог .Net оператора using.

То, как проблему будут решать, не дает понять что за проблема имеется в виду? Это про то, что сейчас надо городить try-finally блоки, если работаешь с ресурсами типа файла? Ну так это не фундаментальная проблема. Просто писанины много.

Просто если Вам надо где-то долго хранить маленький фрагмент большой строки, то надо явным образом снять с него копию.

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

Бессмысленным и беспощадным он будет только если Вы собираетесь хранить ссылку на эту строку вечно. И только если изначальная строка - нереально большая (а это в любом случае ненормально, так как следует использовать поточную обработку). Альтернатива со снятием копии по-умолчанию, создает дополнительные расходы. И во многих случаях они не нужны.

Обратную совместимость - код написанный под 1.6 становится потерянным для 1.4. Разработчиков библиотек принуждают или игнорировать 1.6 или поддерживать несколько версий библиотек.

А что разработчики делают на 1.4? Обслуживают идолы языческих богов?

Что мешает им взять код и библиотеки, что запускались на 1.4 и запускать их на 1.6? Жидкий стул, струящийся по ногам оных или их руководства от страха перед уже несколько лет как не новым? Или может есть иная, более серьезная причина сидеть на старье и не использовать более быстрый сборщик мусора и Swing с аппаратным ускорением?

Если они мутабельны - проблема есть.

Что за проблема? В упор не вижу. Для JVM все строки мутабельны, для программиста — вилы.

Не согласен - предъяви пример, как из одной мутабельной строки мы выдираем подпоследовательности 1-4 и 7-9 и соединяем их вместе. Язык/библиотека могут быть любыми. :)

Интерфейс вызова мог быбыть таким: String s2 = s1.charSequence(1, 4) + s1.charSequence(7, 9);

Реализация этого — засунуть StringBuffer/StringBuilder внутрь класса java.lang.String и не выпячивать наружу. И ВСЁ! К чёрту детали в прикладном коде.

Обратную совместимость - код написанный под 1.6 становится потерянным для 1.4. Разработчиков библиотек принуждают или игнорировать 1.6 или поддерживать несколько версий библиотек.

А что разработчики делают на 1.4? Обслуживают идолы языческих богов?

Миллиарды устройств с J2ME: target=1.4

>> Не согласен - предъяви пример, как из одной мутабельной строки мы выдираем подпоследовательности 1-4 и 7-9 и соединяем их вместе. Язык/библиотека могут быть любыми. :)

Интерфейс вызова мог быбыть таким: String s2 = s1.charSequence(1, 4) + s1.charSequence(7, 9);

OK. Я сейчас пишу String s2 = s1.substring(1,4) + s1.substring(7,9) и у меня все работает. Причем s2 и s1 - immutable.

«под капотом» он создает себе StringBuilder или что ему там взбредет в голову. Мне как бы пофиг. :-)

А где в Вашем примере мутабельность строк - мне не ясно. Следует ли считать, что после s2.charSequence(1,4) s2 изменилась? Если да, то как именно? И зачем? И как тогда работает оператор «+»?

Жабокапец!

Индусы горюют, нормальные программисты открывают шенпанское.

> Лучше бы String сделали мутабельным

Лучи ненависти таким предложениям.

Чем больше в языке иммутабельного - тем меньше стрельбы по ногам. Хотя бы строки - уже неплохой компромисс.

Если он был «атец», то «мамо» была ограниченой шизофреничкой, другое объяснение жабоподелию найти не могу. Ужасный язык, оторвавший у людей в своё время кучу времени и сил. Хуже того - мелкософт обделалась жидким испугом на волну популярности Жабы, да так, что с этого испуга взяла и выкатила .НЕТ! - ещё одно болото, в котором нас купают как котят. Когда же БГ уйдёт продавать хотдоги??

Продвигать нужно D, пока единственный язык для практического применения.