Hi,
Thanks, I'll take a look... I pressed on and I have something (jni based) sort
of working on win32/felix/cygwin/gcc, with caveats... I can provide
source/snippets if you like...
- There were issues getting my win32 dll working, first standalone, and then a
la cpptasks/ANT, but I won't digress on that here unless it becomes apropos; It
was a fight with various compiler options and linker options; The cpptasks does
some things behind the scenes for you, which I have mixed feelings about;
- One thing I'm not clear about... I was under the impression that the
framework, in my case Felix, using the "Bundle-NativeCode:" manifest entry,
would accomplish the System.loadLibrary() on my behalf; That was not the case;
I had to add the static { System.loadLibrary("myLib"); } block to my java code
where the native declaration is made;
# Interestingly, I still need the "Bundle-NativeCode:" entry in the manifest
because it sets up the java library path, for which my forced/manual
System.loadLibrary() statement would otherwise fail to load; Between the two of
them, I managed to load and invoke a native library at run time;
- printf()'s are belated, to say the least; OK, my first round at this was the
proverbial "hello world" JNI with a native printf()... Well, the printf()
statements don't actually appear until I manually shutdown felix at the command
prompt; I guess I can live with that, I just want to make sure that my native
code was executed at the time of invocation, regardless of stdout being
buffered to some side channel of the framework and flushed posthemously; I
tried changing to cout, but that became another nightmare trying to get that to
compile/link (a la cpptasks, nonetheless), so I won't bore you; Just curious as
to how the framework decides it's going to deal with stdout et al;
- I get the sneaking suspicion that framework implementations will not be
consistent; I can live with that, if they are at least consistent on the
basics; I suspect that if I were to attempt to take my hello world to equinox
that it surely would not work (and, I have a mountain of complaints about
equinox being very inconsistent, but that's another discussion thread);
Thanks for your reply, much appreciated, Craig Phillips, Praxis
From: Gunnar Ekolin
Sent: Wed 6/4/2008 3:59 PM
To: OSGi Developer Mail List
Subject: Re: [osgi-dev] Sample Native Code Bundle code
On Wed, Jun 04, 2008 at 09:31:54AM -0400, Craig Phillips wrote:
> Hi, I am a developer using OSGi (preferably Felix and Newton); I am doing a
> lot
> of research/development and have some ability to go off and explore a feature
> set;
>
> I have done more than my fair share of JNI work over the years; I even wrote a
> rather encompassing briefing on JNI, but it's rather dated (circa jdk1.3/
> jdk1.4), so I probably am missing out on generics/typing, but that's a
> tangent.
>
> I would like to explore the OSGi capabilities as expressed in section 3.9 of
> the OSGi R4 core spec, regarding native bundles; I must say, reading the spec,
> I like what I see in terms of the framework's ability to auto-determine the
> native library to load based on metadata and environmental factors;
>
> I was wondering if someone could reply/attach/mail/URL me some sample code.
> unit test / hello world level code is fine. I just want something that gets me
> started. As for platform, I'm sort of doing cygwin/C++/gnu on a windows box
> (XP
> and 2000) although I have a linux/ubuntu load available to me;
>
> Much appreciated, Craig Phillips, Praxis Engineering
>
One, example is the Knopflerfish comm-win32 bundle (also made around
the time of JDK 1.3/1.4):
https://www.knopflerfish.org/svn/knopflerfish.org/trunk/osgi/bundles_opt/serial/comm-win32/
A similar bundle for Linux (commm-linux) is available in a sibling directory:
https://www.knopflerfish.org/svn/knopflerfish.org/trunk/osgi/bundles_opt/serial/comm-linux/
BR,
\GE
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
