strictfp java что это
Вещи, которые вы [возможно] не знали о Java
Эта статья разбавит мой поток сознания о производительности. Поговорим о забавных вещах в яве и околояве, о которых вы возможно не знали. О некоторых из перечисленных я сам узнал недавно, так что считаю, что большинство читателей найдёт для себя хотя бы пару-тройку любопытных моментов.
assert может принимать 2 аргумента
Обычно assert используется для проверки некоторого условия и бросает AssertionError если условие не удовлетворяется. Чаще всего проверка выглядит так:
Однако, она может быть и такой:
За без малого 6 с половиной лет работы с явой расширенное использование ключевого слова assert я видел лишь однажды.
strictfp
Это не ругательство — это малоизвестное ключевое слово. Если верить документации, его использование включает строгую арифметику для чисел с плавающей запятой:
можно лёгким движением руки превратить в
Также это ключевое слово может применятся к отдельным методам:
Подробнее о его использовании можно прочитать в вики-статье. Вкратце: когда-то это ключевое слово было добавлено для обеспечения переносимости, т.к. точность обработки чисел с плавающей запятой на разных процессорах могла быть разной.
continue может принимать аргумент
Узнал об этом на прошлой неделе. Обычно мы пишем так:
Подобное использование неявно предполагает возвращение в начало цикла и следующий проход. Иными словами, код выше можно переписать как:
Однако, вернуться из цикла можно и во внешний цикл, если таковой имеется:
Обратите внимание, счётчик i при возвращении в точку outer не сбрасывается, так что цикл является конечным.
При вызове vararg-метода без аргументов всё равно создаётся пустой массив
Когда мы смотрим на вызов такого метода извне, то кажется, что беспокоится не о чем:
Мы ведь ничего не передали в метод, не так ли? А вот если посмотреть изнутри, то всё не так радужно:
Опыт подтверждает опасения:
Избавится от ненужного массива при отсутствии аргументов можно передавая null :
Сборщику мусора действительно полегчает:
Код с null выглядит очень некрасиво, компилятор (и «Идея») будет ругаться, так что используйте этот подход в действительно горячем коде и снабдив его комментарием.
Выражение switch-case не поддерживает java.lang.Class
Этот код просто не компилируется:
Тонкости присваивания и Class.isAssignableFrom()
А теперь подумайте, какое значение вернёт этот метод:
Мораль: когда кажется — креститься надо надо перечитывать документацию.
Из этого примера проистекает ещё один неочевидный факт:
Открыв исходники java.lang.Integer увидим там вот это:
Глядя на вызов Class.getPrimitiveClass(«int») может возникнуть соблазн выпилить его и заменить на:
Самое удивительное, что JDK с подобными изменениями (для всех примитивов) соберётся, а виртуальная машина запустится. Правда проработает она недолго:
Ошибка вылезает вот здесь :
С упомянутыми изменениями byte.class возвращает null и ломает ансейф.
Spring Data JPA позволяет объявить частично работоспособный репозиторий
Завершу статью курьёзной ошибкой, возникшей на стыке Спринг Даты и Хибернейта. Вспомним, как мы объявляем репозиторий, обслуживающий некую сущность:
Опытные пользователи знают, что при поднятии контекста Спринг Дата проверяет все репозитории и сразу валит всё приложение при попытке описать, к примеру, кривой запрос:
Однако, ничто не мешает нам объявить репозиторий с левым типом ключа:
Этот репозиторий не только поднимется, но и будет частично работоспособен, например, метод findAll() отработает «на ура». А вот методы, использующие ключ ожидаемо упадут с ошибкой:
Всё дело в том, что Спринг Дата не сравнивает классы ключа сущности и ключа привязанного к ней репозитория. Происходит это не от хорошей жизни, а из-за неспособности Хибернейта выдать правильный тип ключа в определённых случаях: https://hibernate.atlassian.net/browse/HHH-10690
На этом всё, надеюсь, мой обзор был вам полезен и интересен.
Поздравляю вас с наступившим Новым годом и желаю копать яву глубже и шире!
Когда я должен использовать ключевое слово «strictfp» в java?
Я посмотрел, что это делает, но у кого-нибудь есть пример того, когда вы будете использовать strictfp ключевое слово в Java? Кто-нибудь нашел применение этому?
будут ли какие-либо побочные эффекты просто положить его на все мои операции с плавающей запятой?
8 ответов
Strictfp гарантирует, что вы получите точно такие же результаты от ваших вычислений с плавающей запятой на каждой платформе. Если вы не используете strictfp, реализация JVM может использовать дополнительную точность там, где она доступна.
в пределах FP-строгого выражения, все промежуточные значения должны быть элементами значения float или double значение, подразумевая, что результаты из всех выражений FP-strict должны быть те предсказано арифметикой IEEE 754 на операндах, представленных с помощью single и двойные форматы. В выражение, которое не является FP-строгим, некоторые отсрочку предоставляется на реализации использовать расширенный диапазон экспонент для представления промежуточные результаты; чистый эффект, грубо говоря, это расчет может привести к » правильному ответ» в ситуациях, когда эксклюзив использование набора значений float или double набор значений может привести к переполнению или сгущенный продукт.
другими словами, речь идет о том, чтобы убедиться, что Write-Once-Run-Anywhere на самом деле означает Write-Once-Get-Equally-Wrong-Results-Everywhere.
с strictfp ваши результаты портативны, без него они более правоподобны для того чтобы быть точны.
Википедия На самом деле имеет хорошую статью об этой теме здесь, со ссылкой на спецификацию Java.
вот несколько ссылок:
и, наконец, фактическая спецификация языка Java,§15.4 FP-строгие выражения:
в выражении FP-strict все промежуточные значения должны быть элементами набора значений float или набора double, что означает, что результаты всех FP-строгих выражений должны быть предсказаны арифметикой IEEE 754 на операндах, представленных с использованием одиночного и двойного форматов. В выражении, которое не является строгим FP, предоставляется некоторая свобода действий для реализации для использования расширенного диапазона показателей для представления промежуточных результатов; чистый эффект, грубо говоря, заключается в том, что расчет может дать «правильный ответ» в ситуациях, когда исключительное использование набора значений float или набора двойных значений может привести к переполнению или сгущенный продукт.
Я никогда лично не использовал его, Хотя.
все началось с истории,
когда java разрабатывался Джеймсом Гослингом, Гербертом и остальной частью его команды. У них на уме была сумасшедшая штука под названием кроссплатформенности. Они хотели сделать дуб (Java) настолько лучше, что он будет работать точно так же на любой машине, имеющей другой набор инструкций, даже с различными операционными системами. Но была проблема с десятичными точками, также известными как плавающая точка и дважды в языках программирования. Некоторые машины были построены эффективность прицеливания в то время как остальные были точность прицеливания. Таким образом, более поздние(более точные) машины имели размер с плавающей запятой как 80 бит, в то время как первые(более эффективные/быстрые) машины имели 64-битные двойники. Но это было против основной идеи создания платформы независимого языка. Кроме того, это может привести к потере точности/данных, когда код построен на некоторой машине(имеющей двойной размер 64 бит) и запускается на другом виде машина (имеющ двойник размера 80 битов).
Как упоминалось в других ответах, это приводит к тому, что промежуточные результаты с плавающей запятой соответствуют спецификации IEEE. В частности, процессоры x86 могут хранить промежуточные результаты с точностью, отличной от спецификации IEEE. Ситуация усложняется, когда JIT оптимизирует конкретное вычисление; порядок инструкций может быть различным каждый раз, что приводит к немного различному округлению.
издержки, понесенные strictfp может быть очень процессор и JIT зависимости. Эта статья Википедии на С SSE2 кажется, есть некоторое представление о проблеме. Поэтому, если JIT может генерировать инструкции SSE для выполнения вычисления, кажется, что strictfp не будет иметь никаких накладных расходов.
в моем текущем проекте есть несколько мест, где я использую strictfp. Существует точка, где потенциальные космические лучи должны быть удалены из значений пикселей. Если какой-то внешний исследователь имеет то же значение пикселя и космический луч перед ними, они должны получите такое же результирующее значение, как и наше программное обеспечение.
strictfp-это модификатор, который ограничивает вычисления с плавающей запятой в соответствии с IEEE 754.
Это можно использовать для всего класса, например «public strictfp class StrictFpModifierExample <>» или для метода » public strictfp void example ()».Если он используется в классе, то все методы будут следовать IEEE 754, а если используется в методе, то конкретный метод будет следовать IEEE 754.
почему он используется. Поскольку разные платформы имеют разные оборудование с плавающей запятой, которое вычисляет с большей точностью и большим диапазоном значений, чем требует спецификация java, которое может производить разный выход на разных платеформах.таким образом, он подтверждает один и тот же выход независимо от различных plateforms
strictfp также обеспечивает для того чтобы принять преимущество скорости и точности выдвинутых деятельностей с плавающей запятой точности.
нет недостатка в этом ключевом слове, которое мы можем использовать, когда мы делаем расчеты с плавающей запятой
мой последний момент-что такое IEEE754 вкратце Стандарт IEEE 754 определяет стандартный способ для вычислений с плавающей запятой и хранения значений с плавающей точкой, либо в одном (32-бит, используется в Java плавает) или Double (64-бит, используется в Java удваивается) точности.Он также определяет нормы для промежуточных вычислений и для расширенной точности форматы.
strictfp является ключевым словом и может использоваться как модификатор без доступа для классов или методов (но никогда не переменных). Пометка класса как strictfp означает, что любой код метода в классе будет соответствовать стандартным правилам IEEE 754 для плавающих точек.
без этого модификатора плавающие точки, используемые в методах, могут вести себя в зависимости от платформы. С его помощью вы можете предсказать, как ваши плавающие точки будут вести себя независимо от базовой платформы, на которой работает JVM. Недостатком является то, что если базовая платформа способна поддерживать высокую точность, а strictfp метод не сможет воспользоваться ею.
SCJP Sun®сертифицированный программист для Java™ 6-Kathy Sierra & Bert Bates
может ниже пример помочь в понимании этого более ясно : В java, когда мы используем поиск точной информации для любой операции, например если мы делаем двойное num1 = 10e+102; двойное num2 = 8e+10 ; результат = поля num1+ пит2
Ключевое слово strictfp в Java
Узнайте, когда и как использовать ключевое слово strictfp в Java.
1. Введение
По умолчанию вычисления плавающих тоных тоок на Java зависят от платформы. Таким образом, точность результатов плавающей точки зависит от использования оборудования.
В этом учебнике мы узнаем, как использовать strictfp на Java для обеспечения независимых платформ плавающих тоных вычислений.
2. строгое использование
Мы можем использовать strictfp ключевое слово как модификатор не доступа для классов, неа абстрактных методов или интерфейсов:
Когда мы объявляем интерфейс или класс с strictfp, все его методы членов и другие вложенные типы наследуют его поведение.
Однако, пожалуйста, обратите внимание, что мы не можем использовать strictfp ключевое слово на переменных, конструкторах или абстрактных методах.
Кроме того, в тех случаях, когда у нас есть суперкласс, отмеченный им, это не сделает наш подкласс наследовать это поведение.
3. Когда использовать?
Java strictfp ключевое слово пригодится всякий раз, когда мы заботимся много о детерминистическом поведении всех плавающей точки вычислений:
С Научно-технический класс использует это ключевое слово, вышеуказанный тестовый случай пройдет на всех аппаратных платформах. Обратите внимание, что если мы не используем его, JVM может свободно использовать любую дополнительную точность, доступную на оборудовании целевой платформы.
Популярным реальным случаем использования для него является система, выполняя высокочувствительные лекарственные расчеты.
4. Заключение
В этом быстром учебнике мы говорили о том, когда и как использовать strictfp ключевое слово в Java.
СОДЕРЖАНИЕ
Основа
В IEEE стандарт IEEE 754 определяет стандартный метод для обоего вычислений и хранения значений с плавающей запятой в различных форматах, в том числе одного (32-бит, используемых в в Java с плавающей точкой float ) или двойными (64-бит, используемой в в Java double ) точности.
До JVM 1.2 вычисления с плавающей запятой должны были быть строгими; то есть, все промежуточные результаты с плавающей запятой должны были вести себя так, как если бы они были представлены с использованием одинарной или двойной точности IEEE. Из-за этого на обычном оборудовании на базе x87 было дорого гарантировать, что переполнение будет происходить там, где это необходимо.
Начиная с JVM 1.2, промежуточным вычислениям по умолчанию разрешено превышать стандартные диапазоны экспоненты, связанные с 32-битным и 64-битным форматами IEEE. Вместо этого они могут быть представлены как члены набора значений «расширенной экспоненты». На таких платформах, как x87, переполнения и потери значимости могут не происходить там, где ожидалось, вместо этого приводя, возможно, к более значимым, но менее повторяемым результатам.
Как это работает
При отсутствии переполнения или потери значимости нет никакой разницы в результатах со strictfp или без него. Если повторяемость важна, можно использовать модификатор strictfp, чтобы гарантировать, что переполнение и потеря значимости происходит в одних и тех же местах на всех платформах. Без модификатора strictfp промежуточные результаты могут использовать больший диапазон экспоненты.
использование
Программисты могут использовать модификатор, strictfp чтобы обеспечить выполнение вычислений, как в более ранних версиях; то есть только с использованием типов IEEE с одинарной и двойной точностью. Использование strictfp гарантирует, что результаты вычислений с плавающей запятой идентичны на всех платформах.
Подготовка к экзамену Oracle Certified Professional Java Programmer
Предисловие
На 16 декабря сего года я назначил себе прохождение экзамена Oracle Certified Professional Java Programmer. Он же Sun Certified Programmer в прошлом. Кроме того я подтолкнул к этому важному шагу еще троих своих товарищей. Начинаем готовиться. Пока вяло, но все же… И чтобы систематизировать получаемые знания, я решил периодически составлять «выжимки» — краткое содержание того, что нашел, прочитал или испытал на собственной шкуре. То, что вы читаете в данный момент — выжимка за номером ноль. Надеюсь, что это поможет кому-то избежать покупки дорогостоящих книг и перелистывания огромного количества статей. Готовлюсь я, кстати, по книге Sun Certified Programmer for Java 6: Study Guide за авторством Kathy Sierra и Bert Bates. Хорошая книга, отличный автор, легкий язык. Рекомендую.
Обращаю внимание, что я не претендую на полное описание всего того, что нужно знать перед экзаменом. Без помощи хаброжителей я подобную работу проделать не смогу, просто потому, что я еще не сдавал сам экзамен. Многое из приведенного ниже может показаться кому-то примитивным. Однако, как показывает практика нарешивания тестов, дьявол кроется именно в деталях. Будем считать это попыткой сжато изложить необходимое от правил именования идентификаторов до подводных камней перегрузки методов при наследовании и далее. Кроме того, я надеюсь подчерпнуть что-то полезное из комментариев людей, которые этот путь уже прошли. В лучшем случае на Хабре появится successfull story с полным описанием того, как все начиналось, росло и развивалось. Поскольку по задумке публиковаться все будет в реальном времени, — раз в двое суток примерно, — то те, кому предстоит сдавать экзамен смогут сравнивать по датам свой темп обучения с нашим и проходить чекпоинты намного быстрее.
Содержание для всей серии
Итак, начнем
Ни для кого не секрет, что все компоненты Java, — будь то классы, переменные, методы или нечто иное, — должны иметь имена или, что звучит немного научнее, идентификаторы. При этом следует учитывать, что есть два уровня «правильности» идентификатора. Во-первых, он должен удовлетворять требованиям языка, а именно:
Во-вторых, идентификатор должен удовлетворять Java Naming Convention. Важно понимать, что даже если идентификатор не является правильным с точки зрения соглашений, он все еще может оставаться валидным для компилятора. Например, компилятор скушает объявление переменной int _$ даже не возмутившись. В ходе экзмена важно понимать, требуется ли определить синтаксическую верность идентификатора, или же нужно понять, удовлетворяет он общепринятому стандарту или нет. Весь стандарт, кстати, с вас никто спрашивать не будет. Важно помнить только несколько фактов:
Вот, собственно, и все основные правила, которых нужно придерживаться. Замечу, правда, что сами авторы книги этим правилам следуют не всегда, за что дико извиняются в самом ее начале. Причной этому, как они говорят, служат особенности утилиты, используемой при интернационализации экзамена. Сертифицированные-то программисты, ИМХО, могли бы и поправить ))
Теперь поговорим немного правилах использования файлов с исходным кодом наших классов.
Модификаторы доступа вы можете в произвольном порядке чередовать с еще несколькими ключевыми словами: final, abstract или strictfp. Вы легко можете объявить класс с модификаторами, скажем, public final strictfp, если вам хочется. Причем порядок не важен. Можно и поменять местами что-нибудь: final public strictfp. Все модификаторы асболютно равноправны. Не стоит только применять final и abstract одноврмененно. Это вызовет ошибку компилятора, так как вы применяете взаимно противоположные по смыслу модификаторы.
Теперь поговорим немного об интерфейсах. О них стоит думать как о полностью абстрактных классах, которые используются для того, чтобы описать, что класс должен делать, не накладывая однако ограничений на то, как именно он это будет делать.
На этом сегодня все. В следующий раз постараюсь подробнее рассмотреть особенности применения модификаторов доступа к полям и методам класса. Кроме того мы рассмотрим примитивные типы, массивы и статические переменные, а также пройдем первый тест для проверки того, насколько все хорошо усвоилось и переварилось. Тест оформлю как форму в Google Docs.
Если кому-то интересно, могу также опубликовать подробную инструкцию, посвященную тому, как на этот экзамен зарегистрироваться через сайты авторизованных партнеров Oracle. Мне лично, чтобы уяснить, где и что выбирать, кому писать и с кем договариваться, пришлось связываться с саппортом Oracle.
Спасибо за внимание и удачного вам экзамена!