After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 480253 - Allow "native" implementations
Allow "native" implementations
Status: RESOLVED FIXED
Product: vala
Classification: Core
Component: general
0.2.x
Other All
: Normal normal
: ---
Assigned To: Jürg Billeter
Vala maintainers
: 510818 (view as bug list)
Depends on: 483840
Blocks:
 
 
Reported: 2007-09-25 15:09 UTC by Sven Herzberg
Modified: 2008-04-20 13:09 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
CNI example, requires g++, gcj, gcjh and libgcj (1.24 KB, application/x-bzip)
2007-09-25 15:10 UTC, Sven Herzberg
Details

Description Sven Herzberg 2007-09-25 15:09:34 UTC
The cygnus native interface for java (CNI) has got a really nice feature: you can write java code like this to get native implementations for functions:

public class Foo {
  public static native void bar();
};

This would be a nice addition for code-wrapping (so one can get the header automatically created first and rely on the implementation from a C file). Also it would be nice if the API for wrappers would be really close to the source file format (»One syntax to rule them all…«).

Will attach a small CNI example.
Comment 1 Sven Herzberg 2007-09-25 15:10:30 UTC
Created attachment 96172 [details]
CNI example, requires g++, gcj, gcjh and libgcj
Comment 2 Jürg Billeter 2007-09-25 15:30:25 UTC
This is already possible to some extent with the [Import] attribute. I'll keep this bug open for now to discuss the best syntax and semantics for files with mixed source code and VAPI declarations.

[Import] in a Vala source file will currently take care of the corresponding declaration in the C header file. That's fine for some cases (using C and Vala code in the same application/library) but doesn't make sense when using [Import] to create an ad-hoc binding to a C library. How should we handle that?

There were also suggestions for the other way round, i.e. how to add actual code to a VAPI binding. We might want to rename the bindings to .vapi and allow .vala files with the same basename to contain helper/wrapper code.
Comment 3 Jürg Billeter 2008-01-21 12:43:47 UTC
*** Bug 510818 has been marked as a duplicate of this bug. ***
Comment 4 Jürg Billeter 2008-04-20 13:09:40 UTC
2008-04-20  Jürg Billeter  <j@bitron.ch>

	* vala/valacfgbuilder.vala, vala/valaclass.vala,
	  vala/valacodecontext.vala, vala/valainterfacewriter.vala,
	  vala/valamember.vala, vala/valamemorymanager.vala,
	  vala/valamethod.vala, vala/valanamespace.vala,
	  vala/valaparser.vala, vala/valascanner.vala,
	  vala/valasemanticanalyzer.vala, vala/valasourcefile.vala,
	  vala/valasymbol.vala, vala/valatokentype.vala,
	  vala/valatypesymbol.vala, gobject/valaccodecompiler.vala,
	  gobject/valaccodegenerator.vala, gobject/valagidlwriter.vala,
	  vapigen/valagidlparser.vala, vapi/packages/gnome-keyring-1/,
	  vapi/packages/gstreamer-0.10/, vapi/packages/gtk+-2.0/,
	  vapi/packages/libgnome-menu/, vapi/packages/pango/:

	  Replace [Import] attribute by `extern' keyword, rename
	  `is_imported' property to `external' and `pkg' property to
	  `external_package' to harmonize used terms, fixes bug 480253

Fixed in r1286.