Серьезно? Формально, одинаковые строковые литералы в Java всегда равны по ссылке (пункт 3.10.5 language spec).
Можете привести пример JVM или настроек, при которых код выше выведет «You should always use String.equals when you want to compare strings for equality»?
Сборщик мусора в любом случае «перемалывает всю кучу», то есть он обязан проверить все ссылки на объект перед тем как как удалять/перемещать его. Про «простые данные и ссылки» не очень понял, можете пояснить в чем вы видите проблему?
>> 1)Изза того, что данные перемещаются в памяти при сборке мусора, то заранее не известен адрес, где объект располагает данные. Каждый раз, когда вы обращаетесь к данным, то происходит не прямое обращение к памяти, а сначала вычисляется адрес данных.
Это не так, начиная где-то с Java 1.4 (а может и раньше).
Объектная ссылка всегда содержит прямой указатель на объект. Когда GC проходит по графу объектов, он также обновляет ссылки (кроме ссылок из мусора, естественно).
IO ещё нехило аллоцирует, конкретно — HashSet внутри Selector’a
Из способов борьбы я знаю: хак из Агроны (подменяющий этот HashSet через reflection), отказ от селектора (если сокетов не очень много), написание своей JNI-обёртки над epoll и сокетами.
Обертки приводят к аллокации памяти (обычно). Аллокация приводит к GC (периодически) и залипанию приложения на пару миллисекунд. В некоторых (очень специфичных) приложениях это залипание неприемлемо.
Я не против велосипедов, у самого их немало. Но сторонние библиотеки все-таки содержат меньше багов (в среднем), причем это не имеет никакого отношения к профессионализму авторов.
Они могут быть трижды новичками и говнокодерами, но если конечный результат использует в проде куча народу, то скорее всего большинство явных косяков было найдено и исправлено (пусть даже медленно и мучительно). Сторонняя библиотека экономит не столько время разработки, сколько время тестирования. К «очередному leftpad»у этот аргумент, естественно, не относится.
У меня к велосипедам отношение простое. Если есть существующее решение, удовлетворяющее всем требованиям, то лучше взять его. Если нет — пишем велосипед. Опять же, помогает при спорах «велосипедофобами»: не нравится велосипед? — предложи альтернативу!
Как уже упомянули выше, для частной компании цель получения прибыль необязательна (в отличии от коммерческой).
Существует куча разновидностей частных некоммерческих компаний, начиная прям с вашего ТСЖ (если оно у вас есть). Ну или если брать пример помасштабнее — ФРС.
Мне кажется, хороший менеджер тоже должен уметь решать difficult задачи. В конце концов, на самом высоком уровне задача коммерческой компании в конкурентной среде тоже difficult — «заработать денег».
Задача менеджеров — перевести эту difficult задачу в инженерные difficult задачи. Чем меньше менеджер способен комфортно работать с этими двумя неопределенностями, тем больше он пытается на своём уровне разбить все на компоненты и процедуры, выстроить дисциплину и жёсткие процессы. Удаётся не всегда.
Инженерам, к слову, тоже стоит помнить о неопределенности вышестоящих задач. А то иногда получается так, что «мы тут все такие творческие и непредсказуемые, нам нужен гибкий процесс, но точную спецификацию того, что нужно будет бизнесу через год, извольте предоставить! Нам же нужно заранее спроектировать красивую архитектуру, а не костыли лепить!»
Нужно быть недалеким закомплексованным хамлом, чтобы пренебрежительно относиться к людям, посвятившим жизнь любимому делу (любому), вместо того чтобы рваться в бизнесмены или менеджеры среднего звена.
Кстати, если вас задел мой комментарий, просто скажите себе: «этот человек ошибается, он сам глуп, и здесь нет повода для расстройства или обиды.»
Prop десков в крупных банках имхо не осталось (спасибо Volcker rule), только хежд фонды. Даже в относительно либеральном cash fx приходится натягивать pre-hedging на глобус чтобы как-то оправдать сам факт наличия ненулевой позиции (если банк большой и хранит кучу пенсий европейских старушек).
Но я бы на месте автора не особо заморачивался с ультра-быстрым HFT. Его тучные годы давно прошли, про FPGA и microwave все в целом знают, и сейчас нужно искать баланс между гибкостью и скоростью. Не факт что этот баланс лежит в области наносекунд. Хотя чисто технически наносекунды конечно интересны и впечатляющи.
Мне очень жаль, что вас огорчило нарушение Open-closed principle в библиотеке из 2 классов без планов расширения.
Ваши замечания насчёт getScale и ArithmeticException противоречат требованиям, из-за которых проект был создан. У меня сложилось впечатление, что вы эти требования не понимаете.
Желаю вам и дальше пребывать в уверенности, что все Java программы должны писаться по одному шаблону и для похожих целей. А все что не укладывается в привычные рамки — трэш и говнокод.
Вашу оценку моей квалификации оставлю без комментариев.
Случайные тесты vs BigDecimal у меня бежали где-то неделю на 2 ядрах (домашняя машина). С юнит-тестами хорошая идея, попробую найти в OpenJDK и позаимствовать.
Реализация JavaMoney на Гитхабе (jsr354-ri) использует BigDecimal внутри. Навскидку — в методе divide. Почему мне не подходит BigDecimal я уже писал. Если вы знаете другую реализацию — поделитесь.
умножать только числа с порядком не больше половины максимального
Нет, умножать/делить/etc можно любые числа при условии что результат вместе с дробной частью влезает в long. Если не влезает, возвращается NaN, который легко проверить. Напомню, Java в случае переполнения типа Long.MAX_VALUE * 10 вообще возвращает мусор.
Ваш первый пример — переполнение (18 нулей до запятой и 4 после):
Насчет "вы уверены?". 100% гарантию отсутствия багов я дать не могу, как и большиство разработчиков. Но класс достаточно хорошо оттестирован, в том числе и на граничных случаях. Если вы нашли конкретную проблему, нет ничего проще написать падающий юнит-тест и прислать мне, я буду очень признателен. У библиотеки нет зависимостей, можно просто скопировать 2 класса из Гитхаба в любой пакет.
Я категорически не приветствую написание велосипедов, но моя исходная задача не решалась стандартными средствами, поэтому пришлось писать по-своему.
Утверждение "любые велосипеды содержат больше багов чем любые не-велосипеды" некорректно.
Серьезно? Формально, одинаковые строковые литералы в Java всегда равны по ссылке (пункт 3.10.5 language spec).
Можете привести пример JVM или настроек, при которых код выше выведет «You should always use String.equals when you want to compare strings for equality»?
www.oracle.com/technetwork/java/whitepaper-135217.html
Object references are implemented as direct pointers. This provides C-speed access to instance variables
Сборщик мусора в любом случае «перемалывает всю кучу», то есть он обязан проверить все ссылки на объект перед тем как как удалять/перемещать его. Про «простые данные и ссылки» не очень понял, можете пояснить в чем вы видите проблему?
Это не так, начиная где-то с Java 1.4 (а может и раньше).
Объектная ссылка всегда содержит прямой указатель на объект. Когда GC проходит по графу объектов, он также обновляет ссылки (кроме ссылок из мусора, естественно).
Да, reflection медленный, но он используется один раз, при создании селектора. Селекторов создаётся мало, обычно один на thread.
IO ещё нехило аллоцирует, конкретно — HashSet внутри Selector’a
Из способов борьбы я знаю: хак из Агроны (подменяющий этот HashSet через reflection), отказ от селектора (если сокетов не очень много), написание своей JNI-обёртки над epoll и сокетами.
Используете что-то из этого?
Обертки приводят к аллокации памяти (обычно). Аллокация приводит к GC (периодически) и залипанию приложения на пару миллисекунд. В некоторых (очень специфичных) приложениях это залипание неприемлемо.
Что из вышеперечисленного неправда?
Они могут быть трижды новичками и говнокодерами, но если конечный результат использует в проде куча народу, то скорее всего большинство явных косяков было найдено и исправлено (пусть даже медленно и мучительно). Сторонняя библиотека экономит не столько время разработки, сколько время тестирования. К «очередному leftpad»у этот аргумент, естественно, не относится.
У меня к велосипедам отношение простое. Если есть существующее решение, удовлетворяющее всем требованиям, то лучше взять его. Если нет — пишем велосипед. Опять же, помогает при спорах «велосипедофобами»: не нравится велосипед? — предложи альтернативу!
Как там Java-версия, достаточно функциональна или лучше подождать? Я бы пару своих проектов проверил.
Как уже упомянули выше, для частной компании цель получения прибыль необязательна (в отличии от коммерческой).
Существует куча разновидностей частных некоммерческих компаний, начиная прям с вашего ТСЖ (если оно у вас есть). Ну или если брать пример помасштабнее — ФРС.
Мне кажется, хороший менеджер тоже должен уметь решать difficult задачи. В конце концов, на самом высоком уровне задача коммерческой компании в конкурентной среде тоже difficult — «заработать денег».
Задача менеджеров — перевести эту difficult задачу в инженерные difficult задачи. Чем меньше менеджер способен комфортно работать с этими двумя неопределенностями, тем больше он пытается на своём уровне разбить все на компоненты и процедуры, выстроить дисциплину и жёсткие процессы. Удаётся не всегда.
Инженерам, к слову, тоже стоит помнить о неопределенности вышестоящих задач. А то иногда получается так, что «мы тут все такие творческие и непредсказуемые, нам нужен гибкий процесс, но точную спецификацию того, что нужно будет бизнесу через год, извольте предоставить! Нам же нужно заранее спроектировать красивую архитектуру, а не костыли лепить!»
Нужно быть недалеким закомплексованным хамлом, чтобы пренебрежительно относиться к людям, посвятившим жизнь любимому делу (любому), вместо того чтобы рваться в бизнесмены или менеджеры среднего звена.
Кстати, если вас задел мой комментарий, просто скажите себе: «этот человек ошибается, он сам глуп, и здесь нет повода для расстройства или обиды.»
Prop десков в крупных банках имхо не осталось (спасибо Volcker rule), только хежд фонды. Даже в относительно либеральном cash fx приходится натягивать pre-hedging на глобус чтобы как-то оправдать сам факт наличия ненулевой позиции (если банк большой и хранит кучу пенсий европейских старушек).
Но я бы на месте автора не особо заморачивался с ультра-быстрым HFT. Его тучные годы давно прошли, про FPGA и microwave все в целом знают, и сейчас нужно искать баланс между гибкостью и скоростью. Не факт что этот баланс лежит в области наносекунд. Хотя чисто технически наносекунды конечно интересны и впечатляющи.
Мне очень жаль, что вас огорчило нарушение Open-closed principle в библиотеке из 2 классов без планов расширения.
Ваши замечания насчёт getScale и ArithmeticException противоречат требованиям, из-за которых проект был создан. У меня сложилось впечатление, что вы эти требования не понимаете.
Желаю вам и дальше пребывать в уверенности, что все Java программы должны писаться по одному шаблону и для похожих целей. А все что не укладывается в привычные рамки — трэш и говнокод.
Вашу оценку моей квалификации оставлю без комментариев.
Реализация JavaMoney на Гитхабе (jsr354-ri) использует BigDecimal внутри. Навскидку — в методе divide. Почему мне не подходит BigDecimal я уже писал. Если вы знаете другую реализацию — поделитесь.
Один маленький падающий юнит-тест, вместо долгих рассуждений на тему «это не заработает»
Нет, умножать/делить/etc можно любые числа при условии что результат вместе с дробной частью влезает в long. Если не влезает, возвращается NaN, который легко проверить. Напомню, Java в случае переполнения типа Long.MAX_VALUE * 10 вообще возвращает мусор.
Ваш первый пример — переполнение (18 нулей до запятой и 4 после):
Ваш второй пример работает нормально:
Насчет "вы уверены?". 100% гарантию отсутствия багов я дать не могу, как и большиство разработчиков. Но класс достаточно хорошо оттестирован, в том числе и на граничных случаях. Если вы нашли конкретную проблему, нет ничего проще написать падающий юнит-тест и прислать мне, я буду очень признателен. У библиотеки нет зависимостей, можно просто скопировать 2 класса из Гитхаба в любой пакет.
Я категорически не приветствую написание велосипедов, но моя исходная задача не решалась стандартными средствами, поэтому пришлось писать по-своему.
Утверждение "любые велосипеды содержат больше багов чем любые не-велосипеды" некорректно.