Community
Participate
Working Groups
System Configuration: RedHat Linux Eclipse M4 (linux, gtk) Summary: The class org.eclipse.swt.internal.gtk.GdkEventKey in the swt-pi.jar (in the org.eclipse.swt.gtk fragment) cannot be resolved when the compiler compliance level is set to 5.0. If the compliance level is set to 1.4 the compiler does not issue any warnings or errors. To Reproduce: Using a fresh installation of eclipse M4 (linux, gtk) in a fresh workspace, the problem can be reproduced by doing the following: 1. Create a plug-in project 2. Create a java class file in the plug-in project with the contents: package your.package.name.here; import org.eclipse.swt.events.PaintEvent; import org.eclipse.swt.events.PaintListener; import org.eclipse.swt.widgets.Canvas; import org.eclipse.swt.widgets.Composite; public class MyCanvas extends Canvas { public MyCanvas(Composite parent, int style) { super(parent, style); addPaintListener(new PaintListener() { public void paintControl(PaintEvent e) { } }); } } 3. MyCanvas should compile using the default compiler compliance level of 1.4. If you change the compliance level to 5.0 and re-compile, the following error is reported: "The type org.eclipse.swt.internal.gtk.GdkEventKey cannot be resolved. It is indirectly referenced from required .class files" 4. The "workaround" when using compliance level 5.0 is to add the swt-pi.jar to the build path as an external jar. However, there should be no need to do this step since everything works when using compliance level 1.4.
One small addition to the "System Configuration" section of my original post: We are using version 9.0 of Redhat Linux
PDE does/must not put JARs from fragments of swt onto the classpath of clients of swt (see bug 45767 for the long discussion as to why). Not sure why the difference between the two compiler levels. Moving to jdt/core to address this issue alone.
I cannot reproduce neither using 3.1 M4 neither HEAD. Do you have more details ?
I really do not have many more details since I don't know exactly what is causing the problem. I can say that I am using the download "eclipse-SDK-3.1M4-linux-gtk.zip". I have tried this on both a linux RH9 machine as well as a core-3 machine. Before running the example, I do a 'rm -rf ~/.eclipse' and always use a fresh workspace (hopefully preventing any cross contamination from other eclipse installations). The other detail I can provide is that on each machine used to reproduce the bug, there is also an installation of eclipse 3.1M3 that I have previously used (but as stated above, I have tried to eliminate any remnants of).
Can you reproduce with latest integration build?
(In reply to comment #5) > Can you reproduce with latest integration build? I'll give it a try and post the results.
(In reply to comment #5) > Can you reproduce with latest integration build? YES ... I just downloaded the latest integration build (Integration Build: I20050209-0800) and tried this on a system running RH9. Once again, the problem exists only when the java compiler compliance level is set to 5.0. Are you able to reproduce the problem on your end on a linux machine running gtk?
Looks like some compiler algorithm in 1.5 mode is requiring more resolution than in 1.4 mode, and thus asking to resolve a missing type (which isn't requested in 1.4 mode). To be investigated during testpass for M5 (no commitment)
I am receiving this same compile error (w/ 1.5 compliance switched to on in GTK/Linux) in Eclipse 3.1m5a. Is there any plan to resolve this issue? It is a major show stopper for us.
Note if you're trying to reproduce this that the win32 fragment only has one .jar (swt.jar) while the GTK+ fragment has multiple jar files.
FYI -- after upgrading to eclipse 3.1 M6, we are no longer experiencing this bug.
It could just be because the SWT fragments are now all single .jar files as we moved to the plugin-as-jar format.
Please reopen if this is still a problem
