4

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:

enter image description here

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?

enter image description here

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

enter image description here

Related questions:

Stefan
  • 10,010
  • 7
  • 61
  • 117
  • 4
    Does `jar --file org.eclipse.swt.3.106.1.v20170926.jar -d` reveal anything? – Alan Bateman Dec 12 '17 at 12:52
  • 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. – Stefan Dec 12 '17 at 13:43
  • 2
    Possible duplicate of [Unable to derive module descriptor for auto generated module names in Java 9?](https://stackoverflow.com/questions/46501388/unable-to-derive-module-descriptor-for-auto-generated-module-names-in-java-9) – Naman Dec 12 '17 at 14:13
  • 1
    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. – Stefan Dec 12 '17 at 14:52
  • 2
    @Stefan True, unless you can(are willing to) modify the jar that you're trying to use. – Naman Dec 13 '17 at 01:34

1 Answers1

8

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

Stephan Herrmann
  • 7,963
  • 2
  • 27
  • 38
  • 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 – Stefan Dec 19 '17 at 09:44
  • 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. – Stefan Dec 19 '17 at 09:55
  • 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. – Stephan Herrmann Dec 19 '17 at 13:46
  • BTW: old `access rules` and Java 9's "is not accessible" are disjoint concepts. – Stephan Herrmann Dec 19 '17 at 13:47
  • I created a min example and filed a bug, see updated question. – Stefan Dec 21 '17 at 14:09
  • 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) – barteks2x Apr 25 '20 at 16:16
  • @barteks2x, which issue are you asking about? https://bugs.eclipse.org/525660 was fixed in 2017. – Stephan Herrmann Apr 25 '20 at 20:57
  • @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. – barteks2x Apr 26 '20 at 18:19
  • @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. – Stephan Herrmann Apr 26 '20 at 21:54
  • @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. – barteks2x Apr 27 '20 at 15:56
  • @barteks2x 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. – Stephan Herrmann Apr 27 '20 at 21:14