3

I'm just trying to get the basic Hello World (project Trial0) application running using:

  • Eclipse Version: 2020-12 (4.18.0)
  • With SWT 4.18 (Linux, GTK)
  • with the Java Compiler set to 15

Following the (kinda ancient, it's about JDK 1.4 and SWT 3.1) description in Developing SWT applications using Eclipse, I have imported the SWT project into Eclipse:

  1. Go to https://download.eclipse.org/eclipse/downloads/index.html#Stable_Builds
  2. Click on "4.18" to reach https://download.eclipse.org/eclipse/downloads/drops4/R-4.18-202012021800/
  3. Scroll down until you reach "SWT Binary and Source" and download the zip swt-4.18-gtk-linux-x86_64.zip.
  4. The zip includes 'swt.jar' (which includes the '.so' files). Launch Eclipse's "File > Import > General > Existing Projects into Workspace", the select the above zip as "Archive File"

I immediately hit a modularization/Jigsaw snag in a project that uses the imported SWT project. The compiler apparently is not allowed to see the SWT classes, which are not modularized:

"The package org.eclipse.swt.widgets is not accessible"

In this code:

package trial;

import org.eclipse.swt.widgets.*;   // "The package org.eclipse.swt.widgets is not accessible"

public class MyApp {

}

Here is the project:

The package org.eclipse.swt.widgets is not accessible

Note the module-info.java file on the importing project. It contains:

module trial0 {
    requires java.desktop;
}

The swt.jar indeed does not advertise modules:

$ jar --file=swt.jar --describe-module
No module descriptor found. Derived automatic module.

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.accessibility.gtk
contains org.eclipse.swt.internal.cairo
contains org.eclipse.swt.internal.dnd.gtk
contains org.eclipse.swt.internal.gtk
contains org.eclipse.swt.internal.image
contains org.eclipse.swt.internal.opengl.glx
contains org.eclipse.swt.internal.webkit
contains org.eclipse.swt.layout
contains org.eclipse.swt.opengl
contains org.eclipse.swt.printing
contains org.eclipse.swt.program
contains org.eclipse.swt.widgets

Do I need to add module-info.java files to the SWT jar? Is there another "canonical" way of pulling the SWT jar up into modularization-land?

David Tonhofer
  • 14,559
  • 5
  • 55
  • 51
  • what is the exact source of your jar file(to reproduce)? and did you try to execute `jar --describe-module --file `? further, you need to use `requires ` to start making use of its packages with modularisation. – Naman Jan 02 '21 at 13:23
  • See [How to list modules within a jar file](https://stackoverflow.com/questions/46616520/list-modules-in-jar-file) – Naman Jan 02 '21 at 13:30
  • @Naman Thank you. I have added more info. – David Tonhofer Jan 02 '21 at 13:35
  • hopefully, eclipse doesn't require any additional configuration to place the jar into the modulepath and then just ensuring the [explicit requires directive](https://stackoverflow.com/a/65539788/1746118) shall work for you – Naman Jan 02 '21 at 13:50

1 Answers1

1

As you could see based on the output describing the module from the jar file.

In your module-info.java file, you shall add the following directive:

requires swt;

This would provide you the access to the package org.eclipse.swt.widgets which the module swt(automatic module name) claims to

contains org.eclipse.swt.widgets

in its description itself.

The file module-info.java of the importing project now contains:

module trial0 {
    requires java.desktop;
    requires swt;
}

Eclipse attaches this warning to the line requires swt;:

Name of automatic module 'swt' is unstable, it is derived from the module's file name.

That's ok.

The above may still not not work. In that case, verify the following:

The project org.eclipse.swt is on the importing project's Modulepath, instead of Classpath:

The importing project's module path must look like this

There needs to be an access rule on the imported module. The following access rules seems to work:

Access rule set up in the importing project

Note that there is nothing specific defined in the "Module Dependencies" for the importing project:

Trial 0 Module Dependencies

David Tonhofer
  • 14,559
  • 5
  • 55
  • 51
Naman
  • 27,789
  • 26
  • 218
  • 353