И, наконец, операционная система на Java в сотовом телефоне!

LG разработала первый в мире телефон с SavaJe OS
08 Ноября, 2005

Компании LG Electronics и SavaJe Technologies объявили сегодня, что LG впервая в мире завершила разработку мобильного телефона с использованием операционной системы SavaJe OS - операционки для мобильных телефонов, построенной на базе технологии Java. Ещё в прошлом году компании заключили партнёрское соглашение и сообщили, что в 2005 году появятся телефоны LG на базе SavaJe OS. И вот, первая ласточка.

LG собирается демонстрировать и продвигать новинку операторам по всему миру и готова приступить в 2006 году к массовому производству телефонов адаптированных под операторские запросы. Модель представляет собой слайдер с цветным TFT-дисплеем разрешением 176х220 пикселей. Телефон оборудован 1,3-Мп камерой и медиаплеером с поддержкой музыкальных форматов MP3, AAC и AAC+, а также видеоформатов H.263 и MPEG4. Есть интерфейс Bluetooth и слот для карточек формата SD.
[img]http://www.mobile-review.com/uploads/20051103_3-.jpg[/img]
Операционка SavaJe представляет собой многозадачную рабочую систему. Она предоставляет богатые возможности для работы с интернетом, мультимедийным контентом, а также может обеспечивать высокий уровень безопасности, обладает гибкостью и лёгко модернизируется под конкретные требования.

Автор: Козлов Алексей

LG Electronics показывает телефон под управлением ОС SavaJe
Операционная система SavaJe OS построена на базе технологии Java компании Sun Microsystems. Особенностью телефона является тот факт, что все приложения и графический интерфейс пользователя написаны на языке Java. По утверждению LG Electronics, это значительно упрощает адаптацию программного обеспечения к требованиям операторов сотовой связи.

Одновременно с открытостью архитектуры, новая ОС обеспечивает высокий уровень безопасности: предусмотрено управление цифровыми правами, совместимое с OMA, (Digital Rights Management, DRM), хранение ключей, управление сертификатами, набор программных интерфейсов Java ME для шифрования, безопасного сетевого соединения, авторизации и идентификации.

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

Источник: http://www.savaje.com/ SavaJe Technologies

Кое-что о Java 6 (Mustang).
Источник: http://www-128.ibm.com/developerworks/java/library/j-jtp09275.html">http://www-128.ibm.com/developerworks/java/library/j-jtp09275.html]http://www-128.ibm.com/developerworks/java/library/j-jtp09275.html
Выделение памяти в стеке
C++ дает программистам выбор между размещением объектов в куче или в стеке. Размещение в стеке эффективнее: выделение памяти дешевле, освобождение совсем ничего не стоит, а язык предоставляет поддержку при разметке сроков жизни объектов, снижая риск забыть освободить объект. С другой стороны, в C++ нужно быть очень внимательным при публикации или совместном использовании ссылок на размещенные в стеке объекты, поскольку они автоматически освобождаются при раскрутке фрейма стека, что приводит к появлению "висячих" указателей.
Еще одно достоинство размещения в стеке состоит в том, что оно куда лучше работает с кешем. На современных процессорах стоимость промаха мимо кеша весьма существенна, так что если язык и runtime могут помочь программе достичь лучшей локальности данных, производительность также повысится. Вершина стека в кеше практически всегда "горячая", а вершина кучи – "холодная" (поскольку с момента последнего использования памяти, скорее всего, прошло немало времени). В результате размещение объекта в куче скорее приведет к большему числу промахов мимо Кеша, чем размещение объекта в стеке.
Что еще хуже, промах мимо кеша при размещении объекта в куче приводит к весьма грязной работе с памятью. При выделении памяти из кучи содержание этой памяти является мусором – битами, оставшимися с момента последнего использования памяти. При выделении не хранящегося в кеше блока памяти из кучи, исполнение приостановится на время переноса содержимого этой памяти в кеш. Затем эти значения будут немедленно переписаны нулями или другими исходными значениями. Все это вместе означает большой объем напрасной работы с памятью (некоторые процессоры, например, Azul Vega, аппаратно ускоряют выделение памяти из кучи).

Escape-анализ
Язык Java не предлагает никакого способа явно разместить объект в стеке, но это не мешает JVM при случае использовать размещение в стеке. JVM могут использовать технику, именуемую escape-анализом (escape analysis), который может определить, что определенные объекты остаются прикованными к определенному потоку на весь срок жизни, и что этот срок жизни ограничен сроком жизни данного фрейма стека. Такие объекты можно безопасно размещать в стеке вместо кучи. Даже лучше, в случае мелких объектов, JVM может полностью избавиться от выделения памяти и просто размещать поля объектов в регистрах.
Листинг 2 показывает пример применения escape-анализа. Метод Component.getLocation() создает защитную копию поля location, так что вызывающая сторона не может случайно изменить текущее расположение компонента. Вызов getDistanceFrom() сперва получает местоположение другого компонента (что включает создание объекта), а затем использует поля x и y объекта, возвращаемого getLocation(), для вычисления расстояния между двумя экземплярами компонентов.
Листинг 2.
public class Point {
  private int x, y;
  public Point(int x, int y) {
    this.x = x; this.y = y;
  }
  public Point(Point p) { this(p.x, p.y); }
  public int getX() { return x; }
  public int getY() { return y; }
}

public class Component {
  private Point location;
  public Point getLocation() { return new Point(location); }

  public double getDistanceFrom(Component other) {
    Point otherLocation = other.getLocation();
    int deltaX = otherLocation.getX() - location.getX();
    int deltaY = otherLocation.getY() - location.getY();
    return Math.sqrt(deltaX*deltaX + deltaY*deltaY);
  }
}Метод getLocation() не знает, что вызывающая сторона собирается делать с возвращаемым им Point; она может удерживать ссылку на него, например, поместив ее в коллекцию, так что getLocation() написан в безопасной манере. Но в этом примере getDistanceFrom() не собирается модифицировать получаемые объекты или запоминать ссылки на них. Он просто собирается ненадолго задействовать Point, а затем избавиться от него, что в данном случае выглядит как разбазаривание ресурсов.
Хорошая JVM может разобраться в происходящем и избавиться от размещения защитной копии. Сначала вместо вызова getLocation() будет подставлено (inlined) тело этого метода, то же будет сделано с вызовами getX() и getY(), в результате чего getDistanceFrom() станет выглядеть так, как показано в листинге 3.
Листинг 3.
public double getDistanceFrom(Component other) {
    Point otherLocation = new Point(other.x, other.y);
    int deltaX = otherLocation.x - location.x;
    int deltaY = otherLocation.y - location.y;
    return Math.sqrt(deltaX*deltaX + deltaY*deltaY);
}Здесь escape-анализ может показать, что объект, создаваемый в первой строке, никогда не покинет своего базового блока и что getDistanceFrom() никогда не изменяет состояние компонента other (под "покинет" имеется в виду то, что ссылка на него не хранится в куче и не передается неизвестному коду, который может удерживать копию). При том, что Point действительно используется только в одном потоке и его время жизни, как известно, ограничено базовым блоком, в котором он размещен, он может быть либо размещен в стеке, либо полностью соптимизирован, как показано в листинге 4.
Листинг 4.
public double getDistanceFrom(Component other) {
    int tempX = other.x, tempY = other.y;
    int deltaX = tempX - location.x;
    int deltaY = tempY - location.y;
    return Math.sqrt(deltaX*deltaX + deltaY*deltaY);
}В результате мы получаем точно такую же производительность, как если бы все поля были публичными, но с сохранением безопасности, предоставляемой инкапсуляцией и защитным копированием (и остальными техниками безопасного программирования).

Escape-анализ в Mustang
Escape-анализ – это оптимизация, о которой говорилось уже давно, и вот, наконец, она здесь – текущие версии Mustang (Java SE 6) могут выполнять escape-анализ и конвертировать выделение памяти в куче в выделение памяти в стеке (или просто избавляться от выделения памяти) там, где это возможно. Использование escape-анализа для устранения некоторых распределений памяти приводит к еще большему ускорению работы с памятью, снижению расхода памяти и уменьшению количества промахов мимо кеша. Кроме того, это снижает нагрузку на сборщик мусора и позволяет реже производить сборку.

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

Brian Goetz

Всё есть.
В 3-й Eclipse в главном меню есть галка "Build Automatically", радом пункты "Build All", "Build Project" - они будут недоступны при взведённой галке. Кроме того, в Навигаторе в контекстном меню тоже появляется пунктик "Build Project" при отключении автоматической сборки.

В общем удобно всё сделано. Осталось дождаться, когда Nokia откроет J2ME Developer Suite 2.2 for Eclipse и можно будет наслаждаться жизнью, а не прозябать на EclipseME.

Ответ на »сообщение 387« (Сергей Тарасов)
___________________________
помешает - надо нанимать специалиста, который будет постоянно работать в режиме, которым никто не пользуется чтоб узнать наиболее удобное сочетание галочек :)

Ответ на »сообщение 386« (Max Belugin)
___________________________

навреное потому, что основной способ работы - компиляция на лету.
Автосохранение перед ручным билдом тут ничем не помешает :)

Ответ на »сообщение 385« (Сергей Тарасов)
___________________________
навреное потому, что основной способ работы - компиляция на лету.

Ответ на »сообщение 380« (Max Belugin)
___________________________

к тому же лечится галкой в настройках
Вполне возможно. Непонятно опять-таки, почему она отключена по умолчанию.

Ответ на »сообщение 383« (iZEN)
___________________________

Вообще-то, Java использует >3млн. профессиональных программистов (по данным Sun в 2003г.).
Доля C/C++программистов неуклонно снижается: кто-то переходит на платформу .Net, кто-то на Java.
(MS уже прекратила сертификацию специалистов-разработчиков C/C++)
Так что в ближайшие 10 лет эти две платформы будут довлеть над сообществом программистов.
Вообще-то эти данные с конференции Борланда, который тоже активно зарабатывает на жабе.
Упоминать данные сана в контексте жабы как-то, ммм... некорректно.
Про мифическое "снижение" С++ников (сколько лет о нем твердят, как молитву) говорит тот факт, что в новой студии микрософт вновь делает С++ первым в стеке. Статья приводилась. С сертификацией это слабо связано: MS не сертифицировала С++-разработчиков, но сертифицировала _виндовых_ разработчков, что суть две большие разницы.

Относительно прогноза, он, видимо, тоже основан на данных отдела маркетинга сана.
Винды растут на серверах более чем на 5% в год (2004г, 1 квартал - 69.4% всех лицензий).
Предполагать, что там в перспективе будет жить жаба можно только по наивности или по глупости.

Ответ на »сообщение 349« (Сергей Тарасов)
___________________________

Пользователей в мире на октябрь 2003
Delphi = ~ 950k
C++ = ~ 4.5 millions
Java = ~2.5 millions

Не густо за 8 лет при таких-то начальных наполеоновских планах.
Вообще-то, Java использует >3млн. профессиональных программистов (по данным Sun в 2003г.).
Доля C/C++программистов неуклонно снижается: кто-то переходит на платформу .Net, кто-то на Java.
(MS уже прекратила сертификацию специалистов-разработчиков C/C++)
Так что в ближайшие 10 лет эти две платформы будут довлеть над сообществом программистов.

Ответ на »сообщение 381« (Jack Of Shadows)
___________________________

я про Save before manual build (или что-то вроде этого)