Investigate the usage of javac plugins

[laeubi]

Now Tycho supports javac as well it might be interesting to supply some functions previously in ecj (e.g. restricted access on packages):

• https://docs.oracle.com/en/java/javase/21/docs/api/java.compiler/javax/tools/Diagnostic.html
• https://github.com/blackbeard334/jops/tree/master
• https://github.com/project-transparent/bermuda

[mickaelistria]

Hooking such checks in the compiler has some drawbacks: it's relatively difficult, not portable to other compilers... The main responsibility of the compiler is to create .class files (of course, some static analysis that is best and most easily done at compilation is hooked in, but it's not a static analyzer). Things that can be checked outside of the compiler would better be a separate/standalone analyzer. For JDT and package restrictions, or more specifically for PDE, I believe it would be more interesting to add a "validate referenced packages" step in the build. This could easily operate on .class files, and list the referenced packages and ensure they're visible according to the resolved dependencies constraints).

[laeubi]

it's relatively difficult, not portable to other compilers...

What other compilers? :-)

For JDT and package restrictions, or more specifically for PDE, I believe it would be more interesting to add a "validate referenced packages" step in the build. This could easily operate on .class files, and list the referenced packages and ensure they're visible according to the resolved dependencies constraints).

That seems an interesting idea but then of course need to be setup as a new step, new invocations, new classpath ... and for some reason was decided to baked into batch compiler or is there any way to call it standalone?

The main "issue" with that I think it that all this require yet another tool to parse and interpret the results, while I hope to reuse the output of the compiler that is already understood by tools.

[akurtakov]

For access to exported package there is also the possible solution of generating module-info.class always that has exports matching OSGi metadata. That combined with only using module path should in theory provide that verification.

[mickaelistria]

and for some reason was decided to baked into batch compiler or is there any way to call it standalone?

As far as I know, those "access rules" are a bit like classpath/package filters in JDT and there is no way to extract this logic easily from ECJ to use it standalone.
But if we do such linkage check as a further step, then this step can be about creating an OSGi wiring context with the dependency and the output bundle (that would allow to validate the produced bundle can be resolved), and for every package referenced by the bundle, check whether there is some wire capable of resolving the package. Maybe just loading all classes of the bundle with its OSGi class loader would do the job well.
As I write it, I realize that it makes Tycho rely more on OSGi instead of JDT/PDE. And I think it's actually a good thing. Maybe BND already has something that can help here?