GetCodeBase апплета возвращает null

У меня есть апплет, и мне нужно открыть поток в файл. Этот файл является локальным файлом, расположенным там, где находятся апплет и HTML-файл: 

    URL localURL = new URL(getCodeBase(), "pixs/icons.zip");
    InputStream localInputStream =localURL.openStream();

Раньше он работал нормально, но после обновления до java 1.7 build 25, getCodeBase() всегда возвращает null. Это действительно документально подтверждено! Увы-нет рекомендации, как ее преодолеть.

Одна вещь, которая сработала, - это использовать полный путь: 

   URL localURL = new URL("file:c:/myFolder/pixs/icons.zip");

Есть ли другой способ решить эту проблему без использования полного пути?

1 3
applet

1 ответ:

возможно, вы можете использовать getDocumentBase вместо этого. Зависит от структуры вашей установки, есть ли тесная связь между базой кода и документами. нет постоянного решения: getDocumentBase был изменен таким же образом в 7u40, согласноошибке #8019177 .

Если нет, то вы можете попробовать использовать getResource чтобы получить URL из вашего JAR, например, файл класса апплета, а затем разобрать этот URL, чтобы получить местоположение JAR и, следовательно, код база. Это непроверенный , так что не стесняйтесь редактировать этот пост, если вы пробовали это.

И последнее, но не менее важное, поскольку это изменение затрагивает только локальные апплеты, вы можете запустить (локальный или общедоступный) веб-сервер для обслуживания этого апплета.

Если вы хотите более официальное заявление по этому поводу, я процитирую отчет об ошибке #8017250 :

Если апплету нужно загрузить ресурс:

  • если ресурс находится в JAR(ах) апплета, они должны быть в состоянии загрузить его с помощью ClassLoader.getResoruceAsStream непосредственно,без необходимости кодовой базы данных.
  • если ресурс находится в arbitary location, а не внутри applet JAR, у них должны быть другие способы добраться до этого местоположения, так как он все равно не является частью ресурса апплета. (например, user.home системное свойство java, при условии, что их апплет имеет все разрешения)

Http://www.duckware.com/tech/java-security-clusterfuck.html (благодаря этот пост ) упоминает некоторые другие альтернативы. Наименее вероятно, что будущие модификации Oracle повлияют на использование location.href в содержащей HTML-странице, например, написание тега <applet> из JavaScript.

2