Блог пользователя RodionGork

Обновляемся до Java 7?
Автор RodionGork, 13 лет назад, По-русски

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

Или уже?

  • Проголосовать: нравится
  • +9
  • Проголосовать: не нравится

13 лет назад, # |
  Проголосовать: нравится +9 Проголосовать: не нравится
Пока нет. Надо подождать пару апдейтов, там есть критические баги оптимизации. Но уверен, ждать осталось не долго. Я провел пару синтетических тестов, новая версия работает примерно на 15% быстрее, что повод радоваться всем пишущим на контесты на Java.
→ Ответить
  • 13 лет назад, # ^ |
      Проголосовать: нравится +3 Проголосовать: не нравится
    Спасибо за скорый ответ!

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

    Поэтому коллег призываю (по крайней мере для домашних и не ответственных нужд) поставить jdk7 паралельно с jdk6... При этом пожалуйста используйте её в т.ч. с ключом "-server"... ;-)
    → Ответить
    • 13 лет назад, # ^ |
        Проголосовать: нравится +4 Проголосовать: не нравится
      Достаточно адекватная статья против появившихся блогов типа "Не используйте Java 7, тама, по слухам, стррррашные баги" и т.п.

      Cay Horstmann - Java 7 unsafe at any speed?

      Баги-то есть вероятно, но их стрррашность вероятно слегка преувеличена из каких-то политико-маркетинговых соображений. Пока единственную проблему я нашёл - виндовый установщик jdk7 не запускается в старой win2000. Есть ещё вопросы к производительности линуксовой версии, но разбираться с этим я ещё не закончил.
      → Ответить
      • 13 лет назад, # ^ |
          Проголосовать: нравится +6 Проголосовать: не нравится
        Да вообще ошибки не критичные
        Циклы же только нубы используют.

        → Ответить
        • 13 лет назад, # ^ |
          ← Rev. 2   Проголосовать: нравится 0 Проголосовать: не нравится

          Вы напишите примерчик с циклом который будет демонстрировать этот баг... Тогда обсудим... ;-)

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

          UPD: Если у вас нет Java7 то не страшно, можно и на Java6 посмотреть - там этот баг тоже есть, если я не путаю.
          → Ответить
          • 13 лет назад, # ^ |
              Проголосовать: нравится 0 Проголосовать: не нравится
            Там в статье ссылки на открытые баги, казалось бы.

            → Ответить
            • 13 лет назад, # ^ |
                Проголосовать: нравится 0 Проголосовать: не нравится
              Я знаю ;-)

              Вот и надо перейти по этим ссылкам, прочитать описание багов и попробовать воспроизвести... :D

              7070134 как назло не воспроизводится, причём не только у меня (хотя я верю что он всё-таки есть, но он явно недоисследован/недоописан - ребята не стали точные входные файлы прикладывать).
              7044738 - в том же духе - баг есть, но судя по количеству голосов до народа не вполне дошло где берётся microbenchmark2.
              → Ответить
13 лет назад, # |
← Rev. 3   Проголосовать: нравится +3 Проголосовать: не нравится

В плане написания решений к задачам порадовало то что появился diamond:

ArrayList<Integer> arr = new ArrayList<>()

И большие константы стало удобнее писать, например

int mod = 1_000_000_009
→ Ответить
  • 13 лет назад, # ^ |
    ← Rev. 2   Проголосовать: нравится +3 Проголосовать: не нравится

    Ну... Как по мне - так разделители в константах и запись двоичных чисел это вообще чепуха... diamond конечно давно ждали т.к. прописывать типы (особенно сложные) по два раза при том что он всё равно потом стирается - это было не тру...

    Вместе с ним по важности я бы поставил строки в свитчах (хотя некоторые пальцатые разработчики считают что свитчи это вообще признак плохого стиля абсолютно всегда).

    Ну а на первом месте я поставлю улучшения связанные с отловом исключений. Хотя вероятно для спортивного программирования это как раз имеет очень малое значение... (я про множественный catch и про try с ресурсиками...)
    → Ответить
    • 13 лет назад, # ^ |
        Проголосовать: нравится 0 Проголосовать: не нравится
      Да, try-with-resources и множественный try это самое крутое в project coin . А при написании кода такой записи констант лично мне не хватало.
      → Ответить
      • 13 лет назад, # ^ |
          Проголосовать: нравится +3 Проголосовать: не нравится
        Я думаю это действительно обусловлено тем что подобные константы достаточно часто встречаются в спортивных задачах, а в прикладном программизьме они обычно перекочёвывают из кода в конфигурационные файлы или БД... Так что спорить не буду ни в коем случае... ;-)
        → Ответить
    • 13 лет назад, # ^ |
        Проголосовать: нравится +5 Проголосовать: не нравится
      , конечно, 
      , т.к
      при том, что он
      свитчи - это вообще

      → Ответить
      • 13 лет назад, # ^ |
        ← Rev. 2   Проголосовать: нравится 0 Проголосовать: не нравится

        Иногда хочется попросить администрацию убивать двойные аккаунты.

        UPD: до кучи ты забыл ещё упомянуть тире после "двоичных чисел", запятую после "считают"... Какой смысл в не 100% корректной корректуре? Всунуться что ли больше некуда?
        → Ответить
  • 13 лет назад, # ^ |
      Проголосовать: нравится +1 Проголосовать: не нравится
    А в то время уже даже в С++ есть auto :о)
    → Ответить
    • 13 лет назад, # ^ |
        Проголосовать: нравится -15 Проголосовать: не нравится
      Э-э-э... Если вы про ключевое слово "auto" то я:
      - вообще не понял к чему это;
      - не представляю кто и зачем (в C++) им пользуется.
      → Ответить
      • 13 лет назад, # ^ |
          Проголосовать: нравится 0 Проголосовать: не нравится
        Наверное, Вы неправильно поняли, про какое auto идет речь. Сишное auto (наследник языка B) обозначает локальную переменную, оно попало в статус deprecated еще когда меня даже на свете не было :). А auto из C++0x обозначает неявно типизированную переменную (аналог var из C#). Пример (явно надуманный):
        auto a = vector<int>(10);
        → Ответить
        • 13 лет назад, # ^ |
            Проголосовать: нравится 0 Проголосовать: не нравится
          Да, точно неправильно понял. Про C++0x стоило упомянуть - я б в гугле нашёл... ;-)

          Если честно, я не уверен что это было нужно, ведь в С++ в отличие от Java для решения таких проблем хватало других способов (макроопределения, тайпдефы). В javascript (как и во многих скриптовых языках) это норма, но в самой java думаю это не появится покуда принято считать что строгая типизация спасает от гипотетических ошибок.

          Ну и честно говоря по этому поводу я горевать не буду. Вот closures действительно хочется поскорее увидеть. Причём, судя по опросам, чуть ли не более чем 40% разработчиков.
          → Ответить
          • 13 лет назад, # ^ |
            ← Rev. 2   Проголосовать: нравится 0 Проголосовать: не нравится

            Строгая типизация никуда не пропадает, собственно. Тип переменной по прежнему однозначно определяется. Однако собственно auto в Java вводить, ИМХО, не нужно, а вот даймонд слева - куда полезнее. Даймонд справа для меня не имеет смысла полностью т.к. Idea это делает сама
            → Ответить
          • 13 лет назад, # ^ |
            ← Rev. 2   Проголосовать: нравится +1 Проголосовать: не нравится

            Ну auto решает, среди прочего, и проблему, которую решает diamond -- можно избежать ввода одного типа дважды.
            А еще:

            map<string, vector<int>> m;
            for (auto it = m.begin(); it != m.end(); ++it)

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

            А еще лямбды можно складывать в auto ;о)

            → Ответить
            • 13 лет назад, # ^ |
                Проголосовать: нравится 0 Проголосовать: не нравится
              Ну да... в общем согласен. От дефайнов/тайпдефов в таких случаях порой уже как-то "нихарашо"...
              → Ответить
13 лет назад, # |
← Rev. 3   Проголосовать: нравится +3 Проголосовать: не нравится

[trollface]Похоже писать сортировку за квадрат так и не отучились.[/trollface]

На самом деле, новая сортировка заметно быстрее старой, но местами выглядит довольно странно.
Например, теперь массивы short/char размера >3200 сортируются подсчетом с выделением массива на 1<<16 int-ов. В то же время сортировать большие массивы int с такой же памятью пораздрядной сортировкой на 2 разряда почему-то не догадались. Не очень логично.

Edit: погорячился насчет памяти, может все-таки дело в ней. Хотя новая сортировка ее тоже не особо старается экономить: например, в
public static void sort(int[] a, int left, int right)
есть строчка
b = new int[a.length];

Если же дополнительной памяти не жалко, простая самопальная сортировка выигрывает: http://pastie.org/2298323
→ Ответить
  • 13 лет назад, # ^ |
      Проголосовать: нравится +2 Проголосовать: не нравится

    На самом деле, есть мнение, что стандартные алгоритмы в яве писали индусы. Там не только сортировка проблемная.
    → Ответить