День добрый!

Есть система которая пересылает объект по сети

на другой стороне есть приёмник

объекты конечно сереализованые. Всё работает... но в силу различных причин решили уйти от посылки целых объектов и посылать потоки битиков. Внимание вопрос как можно сделать преобразование object -> bytesArray -> Object 
Зарание спасибо

Создайте свой интерфейс, где и определите методы toByteArray() и fromByteArray().

но проблемма в том что сообщений тысячи... и в каждом рализовывать эти методы слишком долго... омжет есть какой более универсальный метод?

Я не пойму что ты хочешь. Чем тебе не устраивает универсальная сериализация, и что значит посылать потоки битиков?
Объясни почетче.

Использовать не ObjectOutputStream и ObjectInputStream, а OutputStream и InputStream. Глобально проблемма в том, что мы используем Java IO (в которой и посылаем целые объекты), а в Java NIO на которую мы переходим нет (как мне известно) пересылки объектов... Вот и приходится, чтоб не переделывать все пересылаемые объекты, искать обходные пути. 

1. ObjectOutputStream и ObjectInputStream - это классы которые просто переводят объект в двоичное представление им вообще все равно в какой именно поток им приходится писать. При желании можно сделать обертку и для ByteBuffer и писать в него.
2. NIO не самостоятельная библиотека, а расширение для IO. Тот же FileChannel не создашь без FileInputStream или FileOutputStream.
3. Использовать NIO как самоцель это не разумно. NIO надо использовать если есть проблемы с производительностью и узкое место ввод-вывод. Но это не тот случай, в данном случае "тормозить" будут ObjectOutputStream и ObjectInputStream, т.к. они работают через рефлексию. Если реально проблема с производительностью, то надо писать свои методы toByteBuffer() и fromByteBuffer() - это будет самым быстрым решением.

Если вы собираетесь использовать nio в неблокирующем режиме (а это и есть одно из преимуществ, позволяющее обслуживать много клиентов одним потоком), то вам предстоит решить еще одну проблему.  Чтобы успешно восстановить обьект из массива байтов, необходимо чтобы к этому моменту все байты были на месте, т.е. обьект полностью получен. Но байты передаются по сети порциями и в io необходимый механизм для этого есть. В nio же придется это делать руками. В общем случае, в принимаемом потоке байтов надо распознать начало обьекта, дождаться получения последнего байта обьекта и только после этого можно превратить полученную последовательность байт в обьект одним из перечисленных LSD методов. Весьма интересная задача .

ну звучит очень зловеще... с намёком на разложенные грабельки... Но пока я их(грабелек) не нашол!



смысл: Как только нам приходит что-то на приём выполняем этот кусочек. Вид потока байтов у нас: <objectLength1><object1><objectLength2><object2>... у и соответственно readLength() и readObject() возвращают "да" если удалось считать. Размер текущего сообщения мы всегда сонраняем в глобальную переменную...

Или я чего-то не понял?

Оказывается есть 2 возможности написать преобразование Object -> ByteArray -> Object

Я тут маленький примерчик навоял... 

Если его запустить то он выведет н экран размеры массивов и их длины... 

По скорости они вроде одинаковые... Запускал я 100 000 раз

и оба  варианта выполняли за 3 секунды... НО!!! интерестно почему масивы байтов в которые конвертиться один и тотже Vector разные при чём на 93 байта... 
А теперь внимание вопрос   
1) Мож у кого есть мысли ПОЧЕМУ(разные размеры у массивов)?
2) Какой из двух конвертеров вам кажеться наиболее правильным? 

Правильно вы поняли. Сначала надо посылать размер обьекта в байтах, потом сам обьект. Размер обьекта в общем случае - это целое число, т.е. 4 байта. Чисто теоретически эти 4 байта тоже могут придти не сразу, а по частям 

Потому что стандартный заголовок у сериализации другой (он больше).


Тот который с использованием стандартного ObjectInputStream/ObjectOutputStream.

Извиняюсь за такую настырность(уж очень многое зависит от этого) А ПОЧЕМУ ИМЕННО ЭТОТ?   

т.е если оба гарантируют 100% конвертацию в обе стороны то мне кажеться очевиднее использовать тот при котором меньше надо по сети передавать... так как 1 Vector eto 93 байта а "5 старушек - рупь"   

Это сообщение отредактировал(а) KOp4iK - 10.10.2006, 11:51

Стандартные классы ObjectInputStream/ObjectOutputStream отлажены и проверены ни одним десятком пользователей. Плюс там записывается дополнительная информация которая обеспечивает проверку того, что классы на разных машинах будут идентичны. Помимо прочего там записывается версия протокола.
Без всего этого есть хороший шанс наступить на грабли когда система уже будет работать.

На самом деле ничего зловещего тут конечно нет. 

Ваш поток байтов <objectLength1><object1><objectLength2><object2>...  может передаваться порциями, например так  
<objectLength1><object1><object..pause..Length2><object2>...  

Если вы одним потоком в неблокирующем режиме читаете , то будет так
<objectLength1><object1><object..pause - переход к чтению данных другого сокета..Length2><object2>...  и дочитывать продолжение поток сможет после того, как он обойдет все остальные сокеты . Так что класть размер в глобальную переменную врядли получится.

ну так мы эго с начала в буфер положим и как только считаем >= 4 байт только потом в переменную записывать будем... а пока 4 байта <objectLengthN> не получим readLength() всегда нет возвращать будет 
вроде так  

Добавлено @ 11:13 

Большой пасиб за пояснения. Очн жаль что не получиться экономить