Сообщество Eclipse провело опрос о предпочтениях Java-разработчиков

>Можно пример? Как это чтение по 4 байта и отсутствие битовых преобразований? Как из платформенного порядка байтов перейти к big-endian?

Легко.

Вариант №1: на LE-архитектурах пишем дополнительный код для преобразования LE->BE. Он, с вероятностью в 99%, будет быстрее считывания по байту, а не по 4.

Вариант №2, более универсальный. Учитываем также не-LE и не-BE архитектуры. Пишем в файл c помощью htonl(3), читаем с помощью ntohl(3). Информация в файле будет в LE. Это также будет быстрее варианта на Java.

Примечание: вариант №1 использует #ifdef.

Да, в варианте №1: BE<->LE, если покрываем и чтение, и запись.

Вариант №1: на LE-архитектурах пишем дополнительный код для преобразования LE->BE. Он, с вероятностью в 99%, будет быстрее считывания по байту, а не по 4.

Считывание в любом случае будет вестись блоками. read() возвращает следующий байт и увеличивает внутренний счётчик. Джавовский вариант можно оптимизировать с помощью nio, который, потенциально, тоже ускорит выполнение в сравнение с моим вариантом, но суть не в этом. Да, код на С будет быстрее, я с этим не спорю. Например на полпроцента в конечном счёте. Остальное время программа будет ждать, пока жёсткий диск прочитает очередной блок файла.

Если говорить о более низком уровне, то все эти операции с байтами на современных процессорах безумно быстрые. Оно всё будет в кеше. Без разницы, хоть там будет 10 машинных инструкций, хоть 50. Не они будут причиной тормозов, даже если не будет чтения из файла.

>Например на полпроцента в конечном счёте.

У меня другие ожидания. Начиная от 20% и заканчивая 100%+. Померяем? :)

Конкретно мой вариант будет тормозить, если хочется сравнения с С, то как минимум на nio надо будет переписывать. Можно померяться, но мне надо будет время )

> Зачем создавать знаковые типы разных размерностей и не создавать беззнаковых?

Создатель явы когда-то длинное письмо по этому поводу писал с объяснением. По его мнению, неявные преобразования арифметических типов, когда в них начинают участвовать unsigned модификаторы, начинают вести себя неочевидно. И приводил примеры из Си. Он по своему прав. Для той конкретной проблемы с бинарными типами в яве есть костыль: java.nio.ByteBuffer, посмотри операции put* и get*.

Legioner, открой для себя ByteBuffer

> Вариант №2, более универсальный. Учитываем также не-LE и не-BE архитектуры. Пишем в файл c помощью htonl(3), читаем с помощью ntohl(3). Информация в файле будет в LE. Это также будет быстрее варианта на Java.

Этот вариант реализован на яве с помощью ByteBuffer. Не знаю про скорость, в рилтайме микшировал звук.

Моя основная претензия к менеджеру плагинов, что иногда он не может разрешить зависимости правильно.

Да. Не может. (Не знаю, как в 3.5 и 3.6). Нужно смотреть совместимые с конкретной версией плагины и выбирать их версии.

> 41% разработчиков признались, что используют открытый исходной код из других проектов, и не возвращают свои улучшения! За один год таких разработчиков удвоилось(в прошлом году их было 27%)

с 27 на 41 - это примерно полтора, но никак не два.

26.9% - Java-разработчиков создают приложения для web.

21% - приложений для домашних компьютеров

26.9% - приложений для серверных нужд

вот оно! я всегда подозревал, что подавляющее большинство програм написано не для людей!

«69% разработчиков используют классический Sun/Oracle Java, a OpenJDK всего 21%.»

И куда пропала Oracle JRockit?

Ее не существует, это плод воображения

> програм написано не для людей

А для кого, мой друг, школьник-кун?

«Програм» это от рассового пендостанского слова «program» вместо винрарного британского «programme», как правильно я понял???

Надо же!

А я заказчикам заправляю, что это (наследие BEA) круче, потому как напейсано на Plain Цэ, а не как торадиционная Sun JVM или OpenJDK JVM на поделии, «автору которого место в дурке или на погосте» (с).

Зря.