Where to start debugging PDE?

[datho7561]

I'm working on a project to enable using javac instead of ECJ as the compiler for Eclipse.

We're running into a problem where transitive dependencies of Eclipse plugin projects aren't being added to the classpath during the build, which leads to compilation errors. I'm currently trying to debug to figure out what's going on.

As far as I understand, PDE modifies the classpath of the IJavaProject at some point so that it contains the jars of all the transitive dependencies (which are contained in the p2 bundle pool). I think something might be going wrong during or around this step.

Any general pointers on where to start debugging?

[mickaelistria]

I don't think the compiler is involved in the classpath resolution. The classpath resolution is provided by IJavaProject.getResolvedClasspath() which delegates the container resolution to the right handler (eg PDE) to return a list of "final" classpath entries (libraries, folders...).
You should first verify that the resolved classpath is identical with ECJ or JDT as backend. Then if it is actually identical, you may want to just try building using javac CLI and the same classpath. The question is whether Javac failure is "expected" or not with such classpath.
And if such error happens with javac, you could investigate whether some different configuration of javac would allow it to work.

[datho7561]

Good call. The resolved classpath is the same when using ECJ and when using JDT. I tried it out from the command line with javac with the resolved classpath from the project. I get the same error on the command line about the class from a transitive dependency not being found. This makes sense, because it's not on the classpath.

I'll just need to confirm that it compiles with that classpath with ECJ on the command line

[datho7561]

ECJ doesn't give that error and is able to generate the .class files despite the fact that classes referenced in one of the JARs are not present on the classpath. I guess it doesn't check for the presence of these classes.

Notably, I've configured Tycho to run javac instead of ecj for the project in question (wildwebdeveloper) and the compilation passes under Tycho.

[laeubi]

ECJ doesn't give that error and is able to generate the .class files despite the fact that classes referenced in one of the JARs are not present on the classpath. I guess it doesn't check for the presence of these classes.

ECJ is using "late type binding" (I hope that's the correct term @stephan-herrmann ) and tries to avoid loading actual types if not required, if you are interested you can find a recent change in this area here, javac might work different in this regards.

Notably, I've configured Tycho to run javac instead of ecj for the project in question (wildwebdeveloper) and the compilation passes under Tycho.

Tycho works a bit different in classpath computation and is a bit more "free" in some choices, of course it depends a bit on the project and if you share the failing one it might be possible to explain why you get different results.

I'm currently try to improve PDE in this regard, but for this to give satisfiable results we first need to sort out some current limitations / behavior of how ECJ is handling access restrictions, I started some work here already

• Do not emit restriction warning on inherited method eclipse-jdt/eclipse.jdt.core#4293

[stephan-herrmann]

ECJ doesn't give that error and is able to generate the .class files despite the fact that classes referenced in one of the JARs are not present on the classpath. I guess it doesn't check for the presence of these classes.

ECJ is using "late type binding" (I hope that's the correct term @stephan-herrmann )

Let's reserve "late binding" to method invocations (aka dynamic dispatch etc.)

and tries to avoid loading actual types if not required,

Right, so let's phrase it: ecj reads and analyses types from dependencies on-demand.

And yes there is some degree of freedom, what a compiler wants to analyze.

• in the one extreme a compiler may expect all types that are referenced directly or indirectly to be available during compilation
• there is a minimal but implicit set of reference that need to be followed during compilation in order to comply to JLS

Between the two extremes each compiler chooses a middle ground according to its specific design.

[laeubi]

As far as I understand, PDE modifies the classpath of the IJavaProject at some point

PDE does not modifies the classpath it extends the classpath with a so called classpath container and as such can supply classpath entries.

so that it contains the jars of all the transitive dependencies

That is not always the case. PDE look at the manifest and then adds jar depending on the rules of these imports, but this not necessarily include all transitive dependencies.

(which are contained in the p2 bundle pool)

The bundle pool is just an implementation detail (and it is the pde bundle pool not a p2 one). A classpath entry can came from any source including maven or map to workspace project as well.

Any general pointers on where to start debugging?

If you like to dive into, then look into org.eclipse.pde.internal.core.RequiredPluginsClasspathContainer.computeEntries() what contains the magic on how we compute the actual entries.

[datho7561]

Thanks for the explanation, Christoph! This was very helpful.

If you're interested in the case I was running into, here it is: https://github.com/eclipse-wildwebdeveloper/wildwebdeveloper/blob/master/org.eclipse.wildwebdeveloper.xml/src/org/eclipse/wildwebdeveloper/xml/internal/autoclose/XMLAutoCloseTagReconciler.java#L115 . This is an invocation of a non-API method from org.eclipse.lsp4e. The class LSPEclipseUtils references classes from org.eclipse.core.filebuffers. It seems like javac checks for the org.eclipse.core.filebuffers classes on the classpath when it accesses LSPEclipseUtils.

I don't think javac has this "late type binding" that ECJ has. I'm guessing this would be something you'd have to design the compiler around.

If I add all the transitive dependencies by making the following change, it resolves the issue I'm running into:

diff --git a/ui/org.eclipse.pde.core/src/org/eclipse/pde/internal/core/RequiredPluginsClasspathContainer.java b/ui/org.eclipse.pde.core/src/org/eclipse/pde/internal/core/RequiredPluginsClasspathContainer.java
index fefda5c6b2..181de5c1b8 100644
--- a/ui/org.eclipse.pde.core/src/org/eclipse/pde/internal/core/RequiredPluginsClasspathContainer.java
+++ b/ui/org.eclipse.pde.core/src/org/eclipse/pde/internal/core/RequiredPluginsClasspathContainer.java
@@ -404,9 +404,9 @@ class RequiredPluginsClasspathContainer {

                BundleSpecification[] required = desc.getRequiredBundles();
                for (BundleSpecification element : required) {
-                       if (element.isExported()) {
+                       // if (element.isExported()) {
                                addDependency((BundleDescription) element.getSupplier(), added, map, entries, useInclusion);
-                       }
+                       // }
                }

                if (addImportedPackages) {