Можно и так писать, но это совсем не OOP-style. Особенно публичное свойство onA, которое можно по-всякому менять снаружи, и которое является одновременно объектом, массивом и методом.
Чем не угодил паттерн в классической реализации (типа java.util.Observable в Java) с методами addObserver, deleteObserver и notifyObservers?
Уберите вообще про проблемы. Нет там таких проблем. Проблемы могут быть только у программистов, делающих неверные допущения. Как уже было отмечено, модификатор strictfp обязует JVM производить вычисления в точности по стандарту. Без него результаты представляются с той точностью, которую обеспечивает FPU, что вполне естественно.
Несмотря на потерю производительности, плохое соответствие стандартам о вычислениях чисел с плавающей запятой
А можно поподробнее, каким стандартам Java не соответствует? А то я знаю только IEEE 754, с которым у Java все в порядке.
Ну, а про несправедливость микробенчмарков на Java можно даже не говорить, настолько это распространенная ошибка.
А-а-а! Хочу такой же процессор, как у Вас, чтобы миллиард синусов вычислял за 1 секунду! :))
А то мой Core i7 сто миллионов итераций секунд 5 крутит!
Если серьезно, боюсь, Ваш тест неправилен. Похоже, компилятор выкинул неиспользуемые вычисления в обоих случаях. На самом деле, тест с синусом работает в 6-7 раз медленнее, чем с делением.
Почему везде оговаривают, что граф не должен иметь отрицательных циклов? Алгоритм Флойда отлично справляется и с такой экзотикой. Достаточно к пути, проходящему через вершину i, добавлять поправку Wi = {0, если Dii >= 0; -Inf, если Dii < 0}.
Да, но семантика этого API несколько другая — смысл его в том, чтобы телефон подал уведомление тем способом, которым умеет, а задействование LED при этом вторично. В частности, HTC Desire игнорирует параметры ledARGB, ledOnMS, ledOffMS, и всегда мигает зеленым огоньком со стандартным интервалом, точно так, как при пропущенном звонке или SMS.
То, что не выключается — это фича :) Было задумано, что цвета по кругу меняются, потом на время выключаются и снова все повторяется, однако не на всех телефонах это выглядит именно так. Пожалуй, да — сделаю, что по Quit выключается — не сложно.
Жаль, что у Acer Liquid нет «фонарика». Правда. Но ведь это не повод владельцам HTC отказываться от такой функции, раз уж она поддерживается их телефонами. Я и сам очень надеялся, что Android минует судьба Java ME, где разработчики вынуждены были путем всяких хаков определять модель телефона и использовать те или иные особенности платформы, на которой их приложение запущено. Но, видимо, до тех пор, пока существуют функциональные различия устройств, будут и обходные пути для эксплуатации специфических фич.
Ну, во-первых, это система идентификации абонента, а не стандарт записи произвольного телефонного номера.
Во-вторых, этот формат предназначен для технического обеспечения PSTN, а не для пользовательского интерфейса.
В-третьих, MSISDN касается мобильных сетей GSM и UMTS, но никак не всех телефонных номеров вообще.
В-четвертых, такой формат не предусматривает записи «хитрых» номеров, например, с добавочным кодом.
Нет. В Hotspot объем class metadata ограничен размером Permanent Generation (по умолчанию 64Mb). В JRockit объем class metadata не ограничен, т.е. классы будут загружаться, пока есть свободная физическая и/или виртуальная память. Таким образом, JRockit лишь откладывает проявление утечек памяти, но не избавляет от них насовсем.
на практике, к сожалению, часто бывает OutOfMemoryError: PermGen space
Только в случае утечки памяти. Но на практике, тут Вы правы, утечки памяти бывают часто, даже у опытных Java программистов. Тем не менее, при выгрузке классов Hotspot вычищает из PermGen ВСЕ, что к ним относится, т.е. приложение с правильной организацией динамической загрузки может работать сколь угодно долго.
P.S. Кстати, хорошая новость: скоро PermGen исчезнет из Hotspot'а насовсем.
По умолчанию флаги EliminateAutoBox и DoEscapeAnalysis выключены в стандартных релизах Oracle JDK/JRE.
Чтобы их включить, нужно запустить java с параметром -XX:+AggressiveOpts
Идея понятна, но пример не совсем удачный.
Писать for (Integer i = 0; ...) — дурной тон.
В данном примере лучше не в put заменить int -> Integer, а в цикле Integer -> int.
Во-во. Честно говоря, статья получилась ни о чем.
Ни про URLClassLoader или зачем вообще нужны пользовательские загрузчики, ни про выгрузку классов, ни про взаимоотношения class loading / class linking / class initialization, ни про Class Data Sharing.
Ну, разве что в следующей статье, которая обещана быть интересней…
Чем не угодил паттерн в классической реализации (типа java.util.Observable в Java) с методами addObserver, deleteObserver и notifyObservers?
А можно поподробнее, каким стандартам Java не соответствует? А то я знаю только IEEE 754, с которым у Java все в порядке.
Ну, а про несправедливость микробенчмарков на Java можно даже не говорить, настолько это распространенная ошибка.
А то мой Core i7 сто миллионов итераций секунд 5 крутит!
Если серьезно, боюсь, Ваш тест неправилен. Похоже, компилятор выкинул неиспользуемые вычисления в обоих случаях. На самом деле, тест с синусом работает в 6-7 раз медленнее, чем с делением.
Возможно, HTC специально оставили бэкдор на своих телефонах для своих программ.
Во-вторых, этот формат предназначен для технического обеспечения PSTN, а не для пользовательского интерфейса.
В-третьих, MSISDN касается мобильных сетей GSM и UMTS, но никак не всех телефонных номеров вообще.
В-четвертых, такой формат не предусматривает записи «хитрых» номеров, например, с добавочным кодом.
Лучше будет так:
for (int i = 0; i < xxx; i++) {
Integer I = i;
…
}
Только в случае утечки памяти. Но на практике, тут Вы правы, утечки памяти бывают часто, даже у опытных Java программистов. Тем не менее, при выгрузке классов Hotspot вычищает из PermGen ВСЕ, что к ним относится, т.е. приложение с правильной организацией динамической загрузки может работать сколь угодно долго.
P.S. Кстати, хорошая новость: скоро PermGen исчезнет из Hotspot'а насовсем.
Чтобы их включить, нужно запустить java с параметром -XX:+AggressiveOpts
Писать for (Integer i = 0; ...) — дурной тон.
В данном примере лучше не в put заменить int -> Integer, а в цикле Integer -> int.
Ни про URLClassLoader или зачем вообще нужны пользовательские загрузчики, ни про выгрузку классов, ни про взаимоотношения class loading / class linking / class initialization, ни про Class Data Sharing.
Ну, разве что в следующей статье, которая обещана быть интересней…