Malcolm, ну у меня не из сети читает.

DDDEN!SSS, это понятно, но InputStream - это слишком абстрактный уровень. То есть класс, может быть, на самом деле и не пропустит меньше байтов, чем надо, но InputStream сам по себе предусматривает такую возможность. Допустим, тот же ByteArrayInputStream никогда не выбрасывает IOException при вызове метода read(), но если ты к нему обращаешься как к InputStream, ты обязан ловить IOException.

Malcolm, короче ты к тому, что сам inputStream нивчем не виноват?
ну не знаю, что виновато. сделал цыкл, который вызывает slip, пока все не пропустится и нормально стало.

DDDEN!SSS, просто в InputStream так задумано, что может пропускаться и меньшее количество байт. Вот в подклассах это уже может и уточняться, где и когда, но InputStream сам по себе - это абстрактный класс, который предусматривает все случаи.

По поводу L2CAPConnectionNotifier(или других классов не входящих в ява-машину): как можно избежать ошибок? Есть возможность как то проигноривать создание класса что-ли?

Vampi", если этот класс не жизненно важен для приложения, то можно создать класс, который работает с такими классами и реализовать в нем интерфейс для работы. Дальше создавать класс только через рефлексию (Class.newInstance()), а потом приводить его к интерфейсу. Таким образом, если тот класс, который упоминает несуществующий класс, отрежет, то просто не получится создать его экземпляр. Остальная часть приложения останется в порядке, т.к. она нигде напрямую с тем классом не работает.

Malcolm, честно скажу, понятия не имею о том, что такое рефлекция) Из твоих слов понял, что есть класс "А", содержащий экземпляры "несуществующих" классов, который имплиментит некий интерфейс "С", переопределяет нужные методы. Класс "В" содержит экземпляр класса "А" и его методы принимают в параметры интерфейс "С" (получается класс "В"). Таким образом при вызове методов, работающих с "несуществующими" классами ошибок возникать не должно!? Поправь меня, если я не прав...

Vampi", вроде правильно, если я верно разобрался в твоей терминологии. Просто смысл всей этой махинации в том, что приложение как бы делится на ту часть, которая гарантированно работает, и ту, где упоминаются классы, которых может в итоге не быть, причем эта первая часть нигде не ссылается напрямую на вторую. В твоем примере такая вторая часть - это класс B, а класс A и интерфейс C - это уже первая часть, которая работает всегда.

Но тут возникает проблема: как создать объект класса B, не ссылаясь на него. И вот тогда в дело вступает рефлексия, то есть самоанализ кода. Ты сначала проверяешь возможность работы с недостающими классами через метод Class.forName(). Затем, если нужные классы есть, ты должен вызвать этот же самый метод и получить через него ссылку на объект Class для B. После этого ты пишешь что-то вроде C newObject = (C) bClass.newInstance(), где bClass - ссылка из предыдущего шага. То есть ты нигде класс B напрямую не упоминаешь и команду new не используешь. Единственное - класс B должен иметь конструктор без параметров, иначе newInstance() не сработает.

Malcolm, как оказалось, пример срабатывает не на всех классах. Некоторые классы вроди бы существуют в ява-машине, но при попытке их иницилизации все равно выскакивает ошибка. (Например класс UUID).

Vampi", ты меня, видимо, не так понял, ты должен создать отдельный блок классов, который занимается работой с теми классами, которые могут не существовать. И вот эти самые классы как раз и нужно создавать через рефлексию из всего остального кода, а потом приводить к интерфейсам. А работать с классами, которые могут не быть в JVM, нужно как обычно.

Malcolm, может мы действительно не понимаем друг-друга?) В общем вот мой пример: webfile.ru/5398007 Помоему, я делал так как ты говорил. Может будет время заглянуть в проэкт)