Используя javax.tools. ToolProvider от пользовательского classloader?

Это, кажется, невозможно использовать javax.tools.ToolProvider от пользовательского classloader как требуется Ant или Webstart: http://bugs.sun.com/view_bug.do?bug_id=6548428

javax.tools.ToolProvider.getSystemJavaCompiler() загрузки javax.tools.JavaCompiler в URLClassLoader, родитель которого является системой classloader. API, кажется, не позволяет пользователям указывать родителя classloader.

Как можно использовать javax.tools.JavaCompiler от пользовательского classloader?

Например:

  • Загрузки муравья MyParserTask
  • MyParserTask исходный код Java синтаксических анализов
  • MyParserTask загружается AntClassLoader это делегирует к системе classloader
  • javax.tools.JavaCompiler загружается URLClassLoader thast делегирует к системе classloader

Позже, MyParserTask вызывает:

javax.tools.CompilationTask task = compiler.getTask(...);
com.sun.source.util.JavacTask javacTask = (com.sun.source.util.JavacTask) task;
javacTask.parse().next().accept(visitor, unused); // parsing happens here
  • При наблюдении, как эти два класса находятся на отдельном classloaders, кажется, нет пути к MyParserTask взаимодействовать с JavacTask без получения ClassCastException ошибки.

Какие-либо идеи?

6
задан Gili 23 February 2010 в 14:20
поделиться

2 ответа

Программирование Scala Wampler/Payne имеет пример .

Еще один вопрос SO: Образец совпадающий с Последовательностью как Seq [Char]

И запись блога Daily Scala на unapplySeq .

-121--3977836-

Начиная с версии «Кандидат» все пользователи Windows XP с пакетом обновления 2 теперь заблокированы в Visual Studio 2010. Я не могу обновить этот рабочий компьютер до SP3, что является огромной болью в заднице, так как сейчас я не могу использовать VS2010, если только Microsoft не обходит эту зависимость от SP3 с помощью исправления.

Многие крупные корпорации обновляют свои системы очень и очень медленно, и, таким образом, Microsoft заблокировала множество людей, которые не могут запустить SP3 от ее использования.

-121--4244572-

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

Это обычно является результатом нарушения упреждающего переноса загрузки класса на родительский объект ClassLoader. Проще говоря, любой загрузчик класса должен сначала попросить своего родителя загрузить класс, прежде чем он попытается загрузить его сам. В противном случае возникают всевозможные «интересные» проблемы.

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

0
ответ дан 17 December 2019 в 20:31
поделиться

Эта проблема часто возникает с OSGi. Некоторые люди придумали «загрузчики классов моста», см., Например, эту статью (которая, вероятно, связывает только интерфейсы, а не подклассы, поэтому, возможно, вы не сможете использовать его напрямую).

Если есть только несколько методов, которые вы хотите вызвать для «чужого» объекта, вы также можете обойтись без отражения:

 javax.tools.CompilationTask task;
 task.getClass().getMethod("someMethodInTheSubclassThatICannotSee").invoke("a");

Основываясь на идее отражения, возможно, будет полезен язык сценариев (Groovy, Beanshell , JavaScript).

0
ответ дан 17 December 2019 в 20:31
поделиться
Другие вопросы по тегам:

Похожие вопросы: