How to add org.eclipse.swt (and other plugin dependencies) as an automatic Java9 module?

Question

In order to be able to use my Eclipse plugin "treezCore" also as a Java9 module I created a module-info.java in my src folder.

Furthermore, I moved the Plug-in Dependencies from the Classpath to the Modulepath. I can see a module "org.eclipse.swt.3.106.1.v20170926" in the plugin dependencies:

However, I am not able to reference that module in my module-info.java. I tried

require  org.eclipse.swt.3.106.1.v20170926;
require  org.eclipse.swt;
require  swt;

None of those options worked. The jar file \plugins\org.eclipse.swt_3.106.1.v20170926-0519.jar that is used by Eclipse does not contain a module definition and

jar --file org.eclipse.swt_3.106.1.v20170926-0519.jar -d

says that the module descriptor can not be derived. Also see

Unable to derive module descriptor for auto generated module names in Java 9?

If I download a newer version of swt.jar from

http://download.eclipse.org/eclipse/downloads/drops4/R-4.7.1a-201710090410/download.php?dropFile=swt-4.7.1a-win32-win32-x86_64.zip

I get following output that looks promising:

swt automatic
requires java.base mandated
contains org.eclipse.swt
contains org.eclipse.swt.accessibility
contains org.eclipse.swt.awt
contains org.eclipse.swt.browser
contains org.eclipse.swt.custom
contains org.eclipse.swt.dnd
contains org.eclipse.swt.events
contains org.eclipse.swt.graphics
contains org.eclipse.swt.internal
contains org.eclipse.swt.internal.gdip
contains org.eclipse.swt.internal.image
contains org.eclipse.swt.internal.mozilla
contains org.eclipse.swt.internal.mozilla.init
contains org.eclipse.swt.internal.ole.win32
contains org.eclipse.swt.internal.opengl.win32
contains org.eclipse.swt.internal.webkit
contains org.eclipse.swt.internal.win32
contains org.eclipse.swt.layout
contains org.eclipse.swt.ole.win32
contains org.eclipse.swt.opengl
contains org.eclipse.swt.printing
contains org.eclipse.swt.program
contains org.eclipse.swt.widgets

I also depend on org.eclipse.jface and could not find a seperate download for it.

=> Do I really have to wait for a new release of Eclipse that uses new plugin versions including module definitions?

Or can I somehow reference the old version of swt from the plugins folder, even if it does not include a module definition? I looked for an easy way to define an alias or a fallback dependency e.g.

requires ../plugins/org.eclipse.swt_3.106.1.v20170926-0519.jar as 'org.eclipse.swt'

or

requires org.eclipse.swt fallback ../plugins/org.eclipse.swt_3.106.1.v20170926-0519.jar 

but module-info.java does not seem to support such a syntax.

I have about 20 plugin dependencies and do not want to manually download each of them (if it would be possible) and include them as external jar file. Nor do I want to hack the individual Manifest/jar files in the Eclipse plugin folder. There are many jar files I would need to alter and an update of Eclipse would break that hack.

I am using Eclipse for RCP and RAP Developers, Version: Oxygen.1a Release (4.7.1a), Build id: 20171005-1200

Edit

When using Version: Photon Milestone 4 (4.8.0M4) Build id: 20171214-1849, the error in module-info.java vanishes when using

require org.eclipse.swt;

and having the Plug-in Dependencies in the Modulepath.

However, my imports do not work yet, see following image. If I move the Plug-in Dependencies from the Modulepath to the Classpath, the imports work but the error in module-info.java reappears.

I created a min example at

https://github.com/stefaneidelloth/Java9EclipsePluginExample/tree/master/MyPlugin

and I filed a bug report at

https://bugs.eclipse.org/bugs/show_bug.cgi?id=529089

Related questions:

• How to use 3rd party library in Java9 module?

• Unable to derive module descriptor for auto generated module names in Java 9?

• Force Eclipse (Helios) to use a newer version of SWT at application runtime

• JFace libraries stand-alone download (not picked from Eclipse plug-ins)

• New Keywords in Java 9

Butacaine

Does jar --file org.eclipse.swt.3.106.1.v20170926.jar -d reveal anything? – Cartan

No. The module descriptor can not be determined. Invalid module name:'3' is not a Java identifier. So I guess that the list of "Explicitly included modules" is wrong. – Butacaine

Possible duplicate of Unable to derive module descriptor for auto generated module names in Java 9? – Mcintire

Thank you for the link. If I understand you right I have to wait for a new Eclipse version since I am not the owner of org.eclipse.swt and can't (do not want to) modify it. – Butacaine

@Butacaine True, unless you can(are willing to) modify the jar that you're trying to use. – Mcintire

Answer 1

What you observe is tracked in bug 525660, which starts with the observation that all existing (OSGi) artifacts of Eclipse don't work as automatic modules, because Java 9 fails to derive a valid module name from jar filenames of the shape org.eclipse.swt_3.106.1.v20170926-0519.jar.

Since this was discovered too late to request improving the algorithm for automatic module name derivation, this can only be fixed by adding Automatic-Module-Name headers to the manifests of future releases.

This header is present starting from Photon M4 as can be seen in org.eclipse.swt_3.107.0.v20171205-0742.jar, containing:

Automatic-Module-Name: org.eclipse.swt

Pernell

Photon Milestone 4 (4.8.0M4) does not include the Automatic-Module-Name for all plugins, yet. For example the automatic module name does not work for org.eclipse.ui_3.109.100.v20171116-2149.jar where I would like to use org.eclipse.ui.forms.widgets.FormToolkit – Butacaine

Using org.eclipse.swt as a module dependency seems to work at a first glance because the error in module-info.java vanishes. However, my imports do not work, yet. It says for example "The type org.eclipse.swt.SWT" is not accessible for 'import org.eclipse.swt.SWT;' The access rules for the jar allow the access to org/eclipse/swt/*. The jar org.eclipse.swt_3.107.1.v20171205-0742.jar is shown as "Is not modular - non modifiable" under Plug-in Dependencies in the Modulepath. – Butacaine

Seeing swt as Is not modular seems like the root cause here. Could you please file a bug against PDE (and link it here)? I could also imagine some confusion arising from the fact that Automatic-Module-Name missing in some plugins yields an inconsistent combination. – Pernell

BTW: old access rules and Java 9's "is not accessible" are disjoint concepts. – Pernell

I created a min example and filed a bug, see updated question. – Butacaine

Did the issue get solved? I don't seem to be able to get it to work without adding dependency for specific platform (which won't work if I want it to create builds for all platforms) – Locust

@barteks2x, which issue are you asking about? bugs.eclipse.org/525660 was fixed in 2017. – Pernell

@StephanHerrmann The issue I'm running into is that I have to add platform-specific SWT into module dependencies. Which won't work if I'm building jars for all platforms, for example in gradle. For now I just dropped the idea of using java 9 modules here. – Locust

@barteks2x, that's a different question, from the initial issue of accessibility. You might be having issues with mapping osgi-fragments to modules? Sounds like a suitable follow-up question. – Pernell

@StephanHerrmann The issue is that if I add just the general org.eclipse.swt, the actual classes of swt are still not accessible. I can add any individual platform but that is not viable for me. That seems a lot like the issue from question edit which also seems to be marked as fixed and they appear to expect deveopers to specify exact platform in module dependencies. – Locust

@Locust this question is about eclipse correctly accessing osgi bundles in a JPMS context. This issue has been solved. What you are observing is an inherent difference between OSGi (which has fragments) and JPMS (where you may have to use a mouthful of --patch-module etc). One, is a tooling issue, the other a matter of architecture and of platforms with different capabilities. – Pernell