On 12/30/10 14:41, Bjorn Roche wrote:
On Dec 28, 2010, at 4:54 PM, Richard S. Hall wrote:
On 12/28/10 13:58, Bjorn Roche wrote:
On Dec 28, 2010, at 12:24 PM, Richard S. Hall wrote:
That's gotten me some distance. The app actually launches to a
point. I'm still having two problems, though:
A. My app won't load any JNI stuff no matter what I do.
B. Putting that aside, I get this error:
Caused by: java.lang.NoClassDefFoundError:
com/apple/eawt/ApplicationListener
I don't know about this either. There are some issues with Java and
the Mac Java GUI implementation, something about needing to use the
right thread or something. Maybe it is related...
Hmmm, well I'd love to know what that is exactly, otherwise I may be
SOL. In the meantime, I will try the "exploded bundle" thing and see
if that works any better.
Yeah, maybe someone else knows more.
-> richard
Okay, so I tried your suggestion of building using the exploded
bundle. It works about as well as the "assembly:" and "wrap:" trick,
and both techniques seem to have their pros and cons. I got stuck at
the same point: java.lang.NoClassDefFoundError:
com/apple/eawt/ApplicationListener
To belabor the point, here's the code that failed:
if (os == MAC_OS_X) {
try {
Class<?> osxAdapter =
ResourceUtil.getClass(app,"xowave.util.OSXAdapter");
Class<?>[] defArgs = { OSXApp.class };
Constructor<?> constructor =
osxAdapter.getConstructor(defArgs);
if (constructor != null) {
Object[] args = { app };
constructor.newInstance(args);
}
} catch (Exception e) {
...
}
Now xowave.util.OSXAdapter implements
com.apple.eawt.ApplicationListener, which is only available on mac OS
X, so if the class were loaded directly, it would cause class-loading
problems on non-OSX platforms, so I added the dynamic loading code. (I
don't recall if this is exactly the approach recommended by apple, but
something like it.)
And your bundle imports the "xowave.util" package?
You could always try to com.apple.eawt to the
org.osgi.framework.bootdelegation property, but this still isn't a very
good solution.
I was able to get around this by following Richard's hunch: I simply
by putting the above code in the swing thread with a call to
SwingUtilities.invokeLater().
This strikes me as a bug in OSGi because I should not need to be in a
particular thread to implement an interface no matter what the
interface is.
I don't know if this is the issue, but if it is, the way I understood
it, it is a limitation of the Mac implementation of AWT or something.
I am still stuck loading native code, though. I added this to my
MANIFEST.MF:
Bundle-NativeCode: native/libXOengine-DOUBLE.jnilib ;
native/libXOengine-FLOAT.jnilib ; native/libquaqua.jnilib ;
processor=x86 ;
processor=ppc ;
osname=mac os x
where the paths are relative to my bundle. I have some indication that
this is correct because if I deliberately type change something I get
Native library does not exist
or
No matching native libraries found.
but when my code calls
System.loadLibrary( "XOengine-FLOAT" );
I get
Caused by: java.lang.UnsatisfiedLinkError: no XOengine-FLOAT in
java.library.path
Not sure. It should work. If you can create a simple bundle that fails,
I can try it, since I work on a Mac. Send it to me privately.
-> richard
bjorn
-----------------------------
Bjorn Roche
http://www.xonami.com
Audio Collaboration
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
