Здравствуйте, von Zeppelin, Вы писали:

VZ>Здравствуйте, Географ, Вы писали:
Г>>Я в Java обычно использую класс ByteBuffer для укладки в массив байт всех полей нужных мне данных из класса
VZ>DataInputStream, DataOutputStream еще есть ByteBuffer это все же для работы с NIO.

Согласен. Я не упомянул, что работаю обычно с RandomAccessFile напрямую, позиционируясь на упакованный объект как массив байт. И здесь ByteBuffer уместнее, позволяя ещё и буферизовать поточнее. Заказал, скажем, ByteBuffer длиной 16 килобайт и уже ощутимая прибавка в скорости. При этом возможно перепрыгнуть и назад при необходимости. Но согласен, в общем случае DataInputStream более привычен именно для Java стиля программирования. Просто я не так давно на Java перешёл, года 2 реальных, а был до этого в основном Object Pascal(Delphi), C++ и C#. Отсюда и подсознательное стредмление к низкоуровневости Но я не осуждаю, а даже приветствую Java стиль Он выигрывыает в общности, хотя и может проиграть в частностях. Но это уже философский вопрос.

Кстати, в одной из разработок обнаружил парадокс — если хранить большое количество небольших объектов (как байт-массивы) в памяти (ГИС система), их обработка при выводе (через Swing) занимает не меньше времени, чем считывание нужного набора из файлов и распаковка на лету каждый раз. При этом могу (и делаю так ) использовать только один экземпляр объекта, который себя перестраивает, наращивая нужные буфера по мере необходимости, если следующий объект превосходит по размеру (количество точек в полигоне, например) предыдущий. И потребная память не растёт, т.е. приложение становится хорошо масштабируемым. Так, можно открывать одновременно 1, 2, 3, 5... n карт и память НЕ растёт. Как была 50 мегабайт физической и 50 мегабайт виртуальной, так и остаётся. При этом отдельные файлы занимают на диске от 20 до 50 мегайбайт, а в памяти намного больше.