Java форум JavaTalks

Клиент может сменить ЖВМ? Очень сомневаюсь. Смотрите: среди обычных пользователей используется монопольно сановская ЖВМ (ммм, господ с яблоками прошу удалиться Wink

), а Хармони - пока фтопку (может в будущем дело и изменится). ЖРокит же выполняется только на айбимэшных серваках корпоративными клиентами, которые скорее отдадут сисадмина на расстрел, чем сменят используемую конфигурацию. Поэтому я не поверю, что корпоративный клиент будет менять выбранную изначально ЖВМ, а обычный пользователь пользует сановскую поделку и радуется.
П.С. А вообще есть какая-то спецификация, как ЖВМ должна проводить сериализацию штатными средствами?
_________________
Software and cathedrals are much the same - first we build them, then we pray

JRockit это вообще продукт от BEA, какое он имеет отношение к IBM? Он вполне может работать и на Sun-овских серверах под Solaris-ом. Правда, он ещё та гадость.
Большинство корпоративных клиентов юзают Sun-овскую JVM и на серверах (естественно серверную версию).

Если под разными JRE (даже одной фирмы), то потенциально даже java.lang.Integer может оказаться несовместим. А массивы - такие же основы языка, как и java.lang.Integer, да еще и древнее.

PS разве название темы было "как сериализовать массив в XML"? Нет, спрашивалось про стандартную сериализацию и точка.

Ладно "поставим все точки над i" и закроем тему.

Концептуально сериализация массива не отличается от сериализации объекта класса. Однако с сохранением всех недостатков и преимуществ стандартного механизма сериализации.

Основным недостатком стандартного механизма сериализации является - обратная несовместимость "вверх" сериализованных ресурсов.
Т.е. класс сериализованный с Sun Java 1.6 не может быть десериализован с помощью Java 1.4 (если он умышленно не сериализованн в верисию 1.4), а так-же потенциально с помощью JVM от других поставщиков например IBM или Apple.
Основное-же преимущество - значительно меньший объем файла и соответсвенно более высокая скорость серриализации-десериализации (нежели текстовых файлов, например XML формата). Что может быть всеьма важно, для сохранения и передачи больших объемов данных сохраненных в массиве.

Основным преимуществом сериализации в текстовые данные (например в формате XML) является гибкость и переносимость. Т.е. такие сериализованные ресурсы могут быть использованны как в любом типе JVM так и вообще в любой другой технологии. Ктому же, такие файлы подлежат валидации, и ручному изменению в случае необходимости.
Основной недостаток - существенно больший объем данных, и соответсвенно скорость серриализации/десерриализации.

Т.е. если уверенны в том что: сериализованные ресурсы будут использованны в рамках вашей системы и только внутри выбранной вами версии Java, (например: для передачи этих ресурсов по сети, или веременного сохранения некоторых данных). Размер ресурсов и скорость их обработки для вас имеет высокий приоритет. Тогда ипользуйте стандартный механизм сериализации. В противном случае вы можете использовать мехинизм сериализации в XML.
Если вас неустраивает: ни первый, ни второй варианты, т.е. вам нужна и скорость обработки и переносимость ресурсов, используйте собсвенный механизм сериализации или механизмы от стронних поставщиков.

Все закройте тему.

Разве тема называется "В чем концептуальное отличие простой сериализации от XML-сериализации"? В вашем сообщении выше нет ни слова про сериализацию иемнно массива, все, что вы написали, можно применить к любому другому классу.