Repository navigation
SWT_AWT.initFrame takes (long, String) in Java; the GTK native declares no className and the Cocoa native types it const char * #3665
Description
All three ports declare the same native:
// bundles/org.eclipse.swt/Eclipse SWT AWT/gtk/org/eclipse/swt/awt/SWT_AWT.java:62
static native final Object initFrame (long handle, String className);(cocoa SWT_AWT.java:68, win32 SWT_AWT.java:57, identical.) The win32 implementation matches
it — (JNIEnv *env, jclass that, jlong handle, jstring className). The other two do not:
// bundles/org.eclipse.swt/Eclipse SWT AWT/gtk/library/swt_awt.c:79
JNIEXPORT jobject JNICALL Java_org_eclipse_swt_awt_SWT_1AWT_initFrame
(JNIEnv *env, jclass that, jlong handle)// bundles/org.eclipse.swt/Eclipse SWT AWT/cocoa/library/swt_awt.c:22
JNIEXPORT jobject JNICALL Java_org_eclipse_swt_awt_SWT_1AWT_initFrame
(JNIEnv *env, jclass that, jlong handle, const char *className)The VM binds the native by its short name, which carries no argument descriptor, so javac,
the C compiler and the linker all accept both.
What it can cause
On GTK the VM passes className and the implementation does not declare it; on Cocoa the VM
passes a jstring — a JNI reference — where the implementation declares a C string. Neither
body reads className, so on the calling conventions SWT ships nothing goes wrong today: this
is a mismatch in the declarations, not an observed failure, and I am not claiming a crash. It is
worth closing because nothing in the toolchain would catch it if a body ever started using the
parameter — on Cocoa, reading it as const char * would read the reference as character data.
Called at gtk/.../SWT_AWT.java:171 and cocoa/.../SWT_AWT.java:161.
Fix
Declare jstring className in both, as the win32 port does, with (void)className; to keep the
unreferenced-parameter warning quiet. I am happy to open the PR.
Activity
akurtakov commentedon Oct 4, 2026
Since nothing reads className and you're not seeing a failure, what's the practical case for changing it the way you propose? If it's only to tidy the declarations, I'd rather drop the unused parameter altogether.
GreenFuze commentedon Oct 11, 2026
Good question! You're right, nothing breaks today, and dropping the parameter works for me.
One thing I noticed while looking into it, though:
classNameis whereSWT_AWT.embeddedFrameClassends up. That field is public and documented as "the name of the embedded Frame class", but all three natives ignore it and always create the default class (XEmbeddedFrame,CViewEmbeddedFrameorWEmbeddedFrame). So setting it doesn't actually do anything, apart from theClass.forNamecheck.So if we drop the parameter, it's probably worth saying that in the field's Javadoc (or deprecating the field). Or, if you'd rather have the field work, the natives could use
classNameinstead of the hard-coded name.Happy to send a PR either way, just let me know which you prefer.
akurtakov commentedon Oct 11, 2026
Please drop the className parameter. In the javadoc of embeddedFrameClass mark it as deprecated, forRemoval since=2026-12, and add noreference as described in https://github.com/eclipse-platform/eclipse.platform/blob/master/docs/ApiRemovalProcess.md .
Drop the unused className parameter of SWT_AWT.initFrame
Drop the unused className parameter of SWT_AWT.initFrame
Drop the unused className parameter of SWT_AWT.initFrame
Drop the unused className parameter of SWT_AWT.initFrame
Drop the unused className parameter of SWT_AWT.initFrame