Bug 82290 - JDK tools.jar and Pollinate
Summary: JDK tools.jar and Pollinate
Status: NEW
Alias: None
Product: z_Archived
Classification: Eclipse Foundation
Component: Pollinate (show other bugs)
Version: unspecified   Edit
Hardware: PC Windows XP
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: Carl McConnell CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-01-05 17:25 EST by Carl McConnell CLA
Modified: 2005-01-05 17:31 EST (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Carl McConnell CLA 2005-01-05 17:25:31 EST
Using Pollinate currently requires that Eclipse be invoked with tools.jar on the
boot class path by including something
like the following on the command line:
    -Xbootclasspath/a:C:/java/jdk1.5.0_01/lib/tools.jar
This makes Pollinate hard to use "out of the box", so it would be nice to make
this unnecessary.

The reason this is necessary is somewhat subtle. For the sake of speed, the
Pollinate builder invokes APT
(the Annotation Processing Tool included in the JDK) directly from the JVM
executing Eclipse,
as opposed to starting another JVM as would happen when invoking APT from the
command line. This naturally
means the main APT class is loaded using an Eclipse plug-in class loader. But
APT creates its own class loader
to load the annotation processor factories provided by the user. (For Pollinate,
these are the factories contained
in the Beehive JAR files that process control, page flow, and other
annotations.) Because there are two class loaders in the
picture, a ClassCastException occurs in the absence of the boot class path
argument: APT checks (using instanceof) that each
annotation processor factory implements the AnnotationProcessorFactory
interface, but this fails because the version of this
interface it checks against is the one loaded from tools.jar along with APT by
the Eclipse plug-in class loader, while the factories
implement the version loaded from the class loader created by APT. The only way
to solve the problem is to ensure that the two
class loaders have a common parent that has tools.jar on the path; hence the
boot class path argument. (This essentially happens
automatically when apt is run from the command line, because tools.jar is on the
path of the app class loader that is the implicit
ancestor of the class loader created by APT.)
Comment 1 Carl McConnell CLA 2005-01-05 17:31:38 EST
In update 01 of JDK 1.5, a "process()" method was added to the main APT class
that allows the annotation processor factory to be specified.
An experimental version of the Pollinate builder using this entry point made the
boot class path unnecessary, since the factory came
from the same class loader (an Eclipse plug-in loader) as the main APT class.
However, there are issues: the "process()" entry point accepts
just one annotation processor factory, while for controls two factories are used
as specified in controls.jar in the manifest
services/com.sun.mirror.apt.AnnotationProcessorFactory file. The experimental
builder
tries to compensate by iterating over the factories, but it's not clear that
this produces the same results as before. Also, it produces warning messages like
    warning: Annotation types without processors:
[org.apache.beehive.controls.api.bean.ControlInterface,
org.apache.beehive.controls.api.bean.ControlImplementation]
A solution would be to create some sort of composite factory. But since
Pollinate doesn't have access to tools.jar, which is needed
to define such a factory (because it must implement AnnotationProcessorFactory),
this leads to the problem of building a separate JAR
file containing such a factory. We're tabling this for now, and will come back
to it later.