Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате
Форум программистов > Java: Общие вопросы > ClassNotFoundException


Автор: moes 30.6.2008, 20:53
Всем привет smile

Может быть сталкивался со следующейпроблемой.
У меня есть класс, который наследует интерфеус Serializable:
Код

class MyClass implements Serializable{
//////
}


Я его записывал в файл, при помощи ObjectOutputStream.
И соответственно считывал, используя ObjectInputStream.

Потом я этот класс перенес в другой package.
Теперь при считывании из файла получаю исключение ClassNotFoundException.

Есть ли возможность считать файл? 

заранее спасибо smile

Автор: polosatij 30.6.2008, 21:06


я так думаю, востанови его на прежнем месте, считай и перезапиши то, что у тебя было..  вот..  smile 

Автор: w1nd 30.6.2008, 21:07
Цитата(moes @  30.6.2008,  20:53 Найти цитируемый пост)
Есть ли возможность считать файл?

А изменения ограничиваются только переносом в другой пакет? Состав полей и сигнатуры не менялись?

Автор: moes 30.6.2008, 21:11
Цитата(polosatij @ 30.6.2008,  21:06)
я так думаю, востанови его на прежнем месте, считай и перезапиши то, что у тебя было..  вот..  smile

Это канечно можно, сделать. Но хотелось бы узнать другие возможности.

Добавлено через 1 минуту и 3 секунды
Цитата(w1nd @ 30.6.2008,  21:07)
А изменения ограничиваются только переносом в другой пакет? Состав полей и сигнатуры не менялись?

Изменился толь пакет, больше ничего не менялsmile

Автор: w1nd 1.7.2008, 00:45
Цитата(moes @  30.6.2008,  21:11 Найти цитируемый пост)
Изменился толь пакет, больше ничего не менял

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

Автор: moes 1.7.2008, 10:04
По большому счету хочется убрать зависимость от таких случаев. smile 
Допустим, если файлов очень много и не представляется возможным их перекопирование.
Неужели, если поменять имя класса или в другой пакет его перекопировать нету возможности считать файл.
Я просто думал, что есть какоу-то стандартное средство, которое может на лету подменять имя класса.
 smile 


Автор: LSD 1.7.2008, 10:43
Цитата(moes @  1.7.2008,  11:04 Найти цитируемый пост)
По большому счету хочется убрать зависимость от таких случаев.

Реализуй собственный механизм сериализации.

Автор: moes 1.7.2008, 10:58
Цитата(LSD @ 1.7.2008,  10:43)
Реализуй собственный механизм сериализации.

Это очень трудоемко для данной задачи  smile 

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

Автор: LSD 1.7.2008, 11:27
Цитата(moes @  1.7.2008,  11:58 Найти цитируемый пост)
Просто удивительно, что в случае рефакторинга (просто поменять имя класса или пакет) и уже нету возможности читать файл.  

А почему он должен быть? Подумай, как механизм сериализации должен догадываться о том, идентичны классы или нет.

Автор: moes 1.7.2008, 11:37
Можно было сделать, что-то вроде маппинга.
Чтобы дать возможность делать соответствии между классами.
MyClass -> NewNameMySlass

Тогда JVM будет знать, что если обращаются к классе MyClass,
надо использовать NewNameMyClass.

 smile Возможно ли это реализовать?

Автор: LSD 1.7.2008, 12:04
Цитата(moes @  1.7.2008,  12:37 Найти цитируемый пост)
Возможно ли это реализовать?

Можно. Но реализовывать придется тебе, т.к. создатели JRE посчитали что это нафиг не нужно (и тут я с ними согласен) и создает кучу проблем.

Автор: moes 1.7.2008, 12:12
а можно ссылочку или пример как это можно реализовать.
И вообще сложно ли это? smile 

Автор: LSD 1.7.2008, 12:17
Цитата(moes @  1.7.2008,  13:12 Найти цитируемый пост)
а можно ссылочку или пример как это можно реализовать.

Нет никаких ссылок, смотри как работает сериализация (все исходники доступны) и делай свою с учетом своих требований.


Цитата(moes @  1.7.2008,  13:12 Найти цитируемый пост)
И вообще сложно ли это?

Да.

Автор: moes 1.7.2008, 12:28
 smile  спасибо за помощь!
Думаю легче всего будет вернуть старые имена классов, и пакетов  smile 

Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)