>1. может у твоего телефона уже батарейка сдохла? ;-)

Батарейка изначально такая и была. К тому же я приводил пример когда Java работает и когда нативный код. Кстати, есть и более приземлённый пример. На Nokia E51 тоже хорошо заметно, когда запущено Symbian приложение или Java.

2. ася..? ну вы поняли.

Да, ася. Просто 5 лет назад мой список контактов в Jabber был очень маленький. Я так полагаю вы бы стали тупо сидеть и ждать, что там кто-то появиться?

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

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

> Так зачем корпорациям заморачиваться с выпуском оптимизированных программ

Вот именно, зачем? 98% пользователей же - идиоты, пойдут купят новое железо, если будет тормозить, вместо того, чтобы юзать нормальный софт.

Кратко: http://rexy-craxy.livejournal.com/219159.html

будь ведроидные приложения не на жаве, а на С, например!

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

Офигенная идея! У нас есть китаец на работе, которого зовут Джао. Я называю его Java. Но теперь он станет «Отец Java», потому как он не молод уже. :D

да-да, все идиоты, одни мы Ъ на имаксах в очках сантиметровой толщины

</JavaGuysButthurt>

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

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

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

В энтерпрайзе программисты нужны для решения задач оного.

Тут по умолчанию:
1. Энтепрайз зарабатывает деньги.
2. Программисты автоматизируют работу энтерпрайза.
3. Задачи зачастую приходят весьма размытые, без ТЗ, сроки выполнения безумно маленькие, не говоря уже про количество правок, вносимых в будущем.
4. Простои из-за сбоев программного обеспечения часто стоят несоизмеримо больше зарплаты программистов, а люди ошибаются не зависимо от прямизны их рук. Поэтому, непредсказуемые сегфолты всяких C просто неприемлимы. Любое исключение должно быть отловлено, проанализированно, оказана поддержка пользователям, и исправлена в приложении буквально за минуты.
5. Производительность в энтерпрайзе условна. Если человек делает работу за час, а программа за минуту-две, это нормально. Если на C она будет делать за 30сек - это абсолютно ничего не изменит.

> да-да, все идиоты, одни мы Ъ на имаксах в очках сантиметровой толщины

Если ты не знал, Гослинг написал свой Емакс. И, ЕМНИП, у него очки сантиметровой толщины :D

Гадость java не в идее а в ее реализации.

>ололо, посмотри как в андроидах ява работает и не плакай уже

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

при чём тут он? :)

>Батарейка изначально такая и была. К тому же я приводил пример когда Java работает и когда нативный код. Кстати, есть и более приземлённый пример. На Nokia E51 тоже хорошо заметно, когда запущено Symbian приложение или Java.

Т.е. кривая реализация явы в Симбе и сименсах означает, что ява не нужна вообще? И на чем вы предлагаете писать приложения для мобильных?

> Т.е. кривая реализация явы в Симбе и сименсах означает, что ява не нужна вообще?

Жаба криво реализована в симбе, во всех виндах, в линаксе и во многих мабилках, типа мотороллы, сименса, нокии, сони-эриксон. Найдите мене некривую реализацию жабы... Но увы - с этим-то какраз проблемы. Хотя козалось бы - не вчера технология родилась, могли бы и допилить. Но как тормозила на PIII 600 мегагерц и 128 метров памяти - так и продолжает тормозить но уже на коре квадро в три гигагерца и 8 гигами памяти...

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

Нда. Явасрач.

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

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

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

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

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

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

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

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

У всех трех! А не у 40 000 как сейчас.

> Там до сих пор не было замыканий???!!

и указателей на метод класса тоже нет.

Все это реализовывалось через ... анонимные классы.

А вообще у меня странные чувства по отношению к Java.

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

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

танцы вокруг null

equals и ==

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

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

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

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

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

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

С другой стороны изменили интерфейсы JDBC - поэтому многие вещи, написанные для 1.4, 1.5 тупо скомпилировать под 1.6 не получится.

Haskell!

ужас

>> Т.е. кривая реализация явы в Симбе и сименсах означает, что ява не нужна вообще?

Жаба криво реализована в симбе, во всех виндах, в линаксе и во многих мабилках, типа мотороллы, сименса, нокии, сони-эриксон. Найдите мене некривую реализацию жабы... Но увы - с этим-то какраз проблемы. Хотя козалось бы - не вчера технология родилась, могли бы и допилить. Но как тормозила на PIII 600 мегагерц и 128 метров памяти - так и продолжает тормозить но уже на коре квадро в три гигагерца и 8 гигами памяти...

Седьмая платформа (JP-7) от сони-эрикссонов довольно вменяема. В частности, на последних прошивках K800 ява вполне себе ничего. Хотя, конечно, багов хватает.

сименс такой же ширпотребный как и линукс

Что не фраза - то феерия или 4.2 Ну толсто до невозможности!

> без одерски, сделавшего дженерики для явы, она была бы уже в могиле.

Без чего?

Дженерики испортили язык. Тренд языка пошёл не в ту сторону, в сторону интерпретативных конструкций и функциональщины. Это потянуло дополнительные костыли под это гиблое дело.

Лучше бы String сделали мутабельным и тогда освободились бы от костылей StringBuffer/StringBuilder. И ещё, выкинули бы АРХИТЕКТУРНОЕ_ПОЗОРИЩЕ AWT и Swing из платформы.

>Лучше бы String сделали мутабельным и тогда освободились бы от костылей StringBuffer/StringBuilder.

Ты с ума сошел? Все как раз правильно.

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

Запускай процесс java с параметром -server — будет тупить только во время старта.

Что правильно?

String немутабельный из-за того, что побоялись нарушить условия безопасности.

>String немутабельный из-за того, что побоялись нарушить условия безопасности.

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

>> Лучше бы String сделали мутабельным и тогда освободились бы от костылей StringBuffer/StringBuilder.

Ты с ума сошел?

Это же изя.

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

OpenOffice написан на C++ и отжирает не меньше памяти, чем Eclipse с базовыми плагинами для разработки на Java SE. Число строк кода в Eclipse побольше будет. Латентность (задержка ответной реакции на действия пользователя) в Eclipse сопоставима с таковой в OpenOffice.

Вопросы?

> StringBuilder отлично подходит.

StringBuilder — отличный костыль.
FIXED

>StringBuilder — отличный костыль

Мутабельные строки - это ересь. Аргементация где? Строки за счет иммутабельности отлично работают ключами в хешмапе, сабстринг за O(1) и куча других плюшек. Когда нужно построение строк - StringBuilder. Мутабельные строки - ненужны.

Мутабельные строки - это ересь.

Это не ересь, а суровая необходимость, которую не реализовали изначально.

Аргементация где?

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

Строки за счет иммутабельности отлично работают ключами в хешмапе

И только? А что бы изменилоcь в хашах, будь строки мутабельными? Пришлось бы давать по рукам тем, кто делает из них ключи? Слабенький аргумент в защиту немутабельности.

сабстринг за O(1) и куча других плюшек.

Это так что ли:

/*
 * @(#)String.java	1.205 09/02/26
 *
 * Copyright 2006 Sun Microsystems, Inc. All rights reserved.
 * SUN PROPRIETARY/CONFIDENTIAL. Use is subject to license terms.
 */

package java.lang;

import java.io.ObjectStreamClass;
import java.io.ObjectStreamField;
import java.io.UnsupportedEncodingException;
import java.nio.charset.Charset;
import java.util.ArrayList;
import java.util.Arrays;
import java.util.Comparator;
import java.util.Formatter;
import java.util.Locale;
import java.util.regex.Matcher;
import java.util.regex.Pattern;
import java.util.regex.PatternSyntaxException;

/**
...
 * @author  Lee Boynton
 * @author  Arthur van Hoff
 * @version 1.205, 02/26/09
 * @see     java.lang.Object#toString()
 * @see     java.lang.StringBuffer
 * @see     java.lang.StringBuilder
 * @see     java.nio.charset.Charset
 * @since   JDK1.0
 */

public final class String
    implements java.io.Serializable, Comparable<String>, CharSequence
{
    /** The value is used for character storage. */
    private final char value[];
...
    public String substring(int beginIndex, int endIndex) { 
        ... 
        return ((beginIndex == 0) && (endIndex == count)) ? this : 
           new String(offset + beginIndex, endIndex - beginIndex, value); 
    }
}

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

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

Займись C#. Там такого нет. Там и в документацию чужой либы придётся долго втыкать, когда у клиента, запустившего приложение, ВНЕЗАПНО появились непонятные буквы в стектрейсе, а приложение сдохло. Конечно, всё можно списать на недостатки тестирования, но этот случай мог бы пойматься ещё на этапе компиляции, а не в готовой программе.

(Проверяемые исключения самодокументируют код исходники/документация на который недоступны. Если библиотека написана на Java грамотно, то её можно поставлять без исходников при минимуме документации — остальное подскажет компилятор.)

98% пользователей же - идиоты, пойдут купят новое железо, если будет тормозить, вместо того, чтобы юзать нормальный софт

Редактор Слово&Дело? «640кбайт будет достаточно для любого разработчика»

У меня всего 2 ссылки для тебя http://forum.ixbt.com/topic.cgi?id=15:46970-4 http://habrahabr.ru/company/intel/blog/90142/

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

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

Это не ересь, а суровая необходимость, которую не реализовали изначально.

http://to./3kj9

Если бы на Java была написана планета земля то не было бы самоубийц, потому что была бы предусмотрена защита и от этого. Даже погибнуть под машиной было бы нельзя - потому что при переходе через дорогу создавалась бы копия.

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

http://ru.wikipedia.org/wiki/Android Также есть возможность писать приложения на Си и других языках программирования с помощью Android Native Development Kit, например

Тим Брей (Tim Bray), известный как сооснователь Open Text Corporation и Antarctica Systems, директор по веб-технологиям в Sun Microsystems, перешел в компанию Google, где займется мобильной Linux/Java-платформой Android http://www.nixp.ru/news/Тим-Брей-(Sun)-займется-Android-в-Google.html

Походу, Гослинга возьмут туда же

Попробовал поискать google://android why java is chosen as main language и наткнулся на это

«In fact, this problem is not difficult to understand, if you know it is aware of mobile development platform for Symbian Series60 using Native C + +, but more tend to STL library types through typedef whole become more uncertain, because the predecessor Epoc framework for resource constrained mobile devices, there are at present more and more time there is not in conformity with the requirements of the development, at least on development efficiency can not meet current development, even if the S60 smart machine is mainly used as a Symbian J2ME game development platform. »

В переводе с китайского английского я понял так, что под Symbian пытались писать эффективные приложения на фреймворке Epoc/C++ но банально не поспевали выпускать приложения в срок

Вот еще http://mantrid.wordpress.com/2008/04/28/do-android-dream-of-something-more-th...

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

и?

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

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

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

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

Хорошо устроились.

По моему опыту, у Java тормозит все, что имеет графический интерфейс, но вот приложения без графического интерфейса работают вполне прилично.

А по теме думаю, что Гослинг ушел, потому что его не устроили новые условия работы в Oracle. Думаю, они что-то изменили, что ему категорически не понравилось, и чтобы работать там дальше, надо было бы «изменить» своим убеждениям.

Хорошо устроились.

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

>не было бы самоубийц

Нее - самоубийцы бы были. Но они бы убивали себя только в случае перенаселении планеты.

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