Не понимаю вашей логики. Плохой софт и software bloat всегда были и будут. Равно как и быстрый и хорошо оптимизированный софт. Рост производительности железа просто дает разработчикам новые возможности. Многие из совершенно стандартных сейчас функций софта раньше выглядели слишком тормозными или бесполезными. Если эти функции лично вам не нужны — вы можете просто от них отказаться; возьмите старый Pentium и будьте счастливы. А я все-таки предпочту тратить пару минут, а не полчаса, на кодирование CD в MP3 и заливку на плейер. И буду читать gmail и google reader, не отключая javascript.
Судья на самом деле решил, что сладкая парочка хотела просто срубить денег с Google. Если бы им действительно была важна приватность, то они могли бы обратиться напрямую в саппорт Google и не подавать иск. А так им пришлось согласиться с публикацией личных данных, да еще и шум на весь интернет подняли.
Да, в результате у вас будет объект, соответствующий литералу «foo» и еще два разных объекта — str1 и str2. При этом с точки зрения метода equals они будут равны.
Насчет strValue не очень понятно — нет такого метода в стандартной Java. В Sun-овской реализации есть внутреннее поле char[] value, которое действительно будет ссылаться на один и тот же объект-массив символов. Но снаружи к этому полю доступа нет, ибо это детали реализации, на которые полагаться не стоит.
Брюс в целом прав, но, скажем, в Sun JVM есть несколько алгоритмов сборки мусора. Во-первых, объекты разбиты на поколения, обрабатываемые разными сборщиками мусора. Короткоживущие объекты живут в отдельной области памяти и, попадая в мусор, убираются очень быстро; долгоживущие переселяются в основной heap. Во-вторых, большая часть работы по чистке долгоживущих объектов от мусора может выполняться в отдельном потоке, параллельно с выполнением полезного кода. Так что паузы можно свести к минимуму.
Есть еще такая фича как escape analysis, позволяющая JVM размещать совсем уж короткоживущие (т.е. не выбирающиеся за пределы текущего метода) объекты на стеке. Память, занятая такими объектами, автоматически освобождается сразу после выхода из метода.
Если подробнее, то Java-машина создает по одному String-объекту для всех одинаковых строковых констант (литералов), встречающихся в программе. Значением выражения «aaa» будет всегда один и тот же объект класса String, независимо от того, в скольки местах в программе встречается это «aaa».
А вот выражение new String(«aaa») создаст совершенно новый экземпляр строки, в который будет скопировано содержимое «aaa».
А моды — это точно разные длины волн? Я всегда думал, что это просто разные пути распространения сигнала.
Даже одномодовое волокно будет пропускать приличный кусок спектра обычного светодиода, а не только свет с определенной длиной волны.
Насчет strValue не очень понятно — нет такого метода в стандартной Java. В Sun-овской реализации есть внутреннее поле char[] value, которое действительно будет ссылаться на один и тот же объект-массив символов. Но снаружи к этому полю доступа нет, ибо это детали реализации, на которые полагаться не стоит.
Есть еще такая фича как escape analysis, позволяющая JVM размещать совсем уж короткоживущие (т.е. не выбирающиеся за пределы текущего метода) объекты на стеке. Память, занятая такими объектами, автоматически освобождается сразу после выхода из метода.
А вот выражение new String(«aaa») создаст совершенно новый экземпляр строки, в который будет скопировано содержимое «aaa».
Даже одномодовое волокно будет пропускать приличный кусок спектра обычного светодиода, а не только свет с определенной длиной волны.
Никакой хэш не является однозначным идентификатором сообщения.