Code assist is EXTREMELY slow for whatever reason on the HELIOS J2EE build. This wasn't happening before on Galileo. So I did some researching and found this nifty note on the interweb...
If you are using the JEE edition of HELIOS, the assists can be speeded up by turning off JAX-WS assist in the edit/advanced preference (Window->Preferences->Java->Editor->Content Assist->Advanced. It also appears that the assists cycle through a list of suggestion sources, starting with a different one each time, which would explain why the assists are not always slow.
Sped things up, but still slow... so then I checked for more links and ended with this one: https://bugs.eclipse.org/bugs/show_bug.cgi?id=317979
It states the bug is fixed in newer release of the Eclipse SDK. Too bad this still doesn't work!
Finally I reverted to GALILEO, and the issue is no more. It must be an issue on Android end, and not eclipse.
MACPORT: 1.9.1 + OSX 10.6.4
While attempting to install Android environment, it prompted me to install MACPORT, followed by this command:
POSIXLY_CORRECT=1 sudo port install gmake libsdl git-core gnupg
Which crashes when attempting to install db46, with a jni.h not found error. Some quick searching on the interweb later, I found this issue exists (probably) with the java sdk installed with Snow Leopard... and the fix is to install this dmg:
https://connect.apple.com/cgi-bin/WebObjects/MemberSite.woa/wa/getSoftware?bundleID=20719
or direct link to the dmg:
http://connect.apple.com/cgi-bin/WebObjects/MemberSite.woa/wa/getSoftware?fileID=26495&wosid=3h7EYNxPvekL2pGKzaKoAl6riR9
Edit: So this doesn't actually work for me, and I suspect it's because I'm on 10.6.4, not 10.6.3... but either way, I figured out how to get past db46:
copy and paste the content in:
/Developer/SDKs/MacOSX10.6.sdk/System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Headers
into:
/opt/local/include
After db46 is installed, be sure to remove these additional header files... it's a bad hack.
IPHONE: Binary Submission + Invalid Binary
Kept getting this odd INVALID BINARY error message today whenever I'd try to submit my binary.
The problem is I submitted my binary earlier this week as a iPhone-ONLY application, but wanted to go back and change it to be a 'Universal' build.
There used to be an option in Itunes Connect to choose which devices you wanted to target, but now it's all just handled in your application building process.
Anyway here's the settings for the ORIGINAL build that was an 'acceptable' build:
- Architecture: Standard (armv6 armv7)
- Base SDK iOS: Device 4.1
- Targeted Device Family: iPhone
- iOS Deployment Target: iOS 4.0
Here's what I tried to change the build to, which caused the INVALID BINARY error:
- Architecture: Standard (armv7)
- Base SDK iOS: Device 3.2
- Targeted Device Family: iPhone/iPad
- iOS Deployment Target: iOS 3.2
Here's what finally worked (universal build):
- Architecture: Standard (armv6 armv7)
- Base SDK iOS: Device 4.1
- Targeted Device Family: iPhone/iPad
- iOS Deployment Target: iOS 3.2
Too lazy to test exactly what was the cause of the issue, but it's obviously between the 'Architecture' or the 'Base SDK iOS'. My guess is the Architecture over Base SDK... but who knows.
JNI + MAC OS X: Simple sample
Couple things to be aware of:
#1. for MAC OS X, the binaries end with .dylib or .jnilib (not .so, .dll)
#2. when compiling the shared lib, you should split up the compilation from the linking
#3. when compiling the shared lib in MAC OS X, be sure to specify the JavaVM framework
The code is like every other JNI example, so I wont post it here. The actual problem was in the command-prompt commands... which should go something like this:
javac HelloWorld.java
javah -jni HelloWorld
cc -c -I/Library/Java/Home/include helloworld.c
cc -dynamiclib -o libhelloworld.jnilib helloworld.o -framework JavaVM
java HelloWorld
5 simple lines...
Do not use the following line to compile for MAC OS X, it will give you all sorts of complaints:
[g]cc -dynamiclib [-G] [-m32] -o helloworld.dylib -I/Library/Java/Home/include [-arch i386] helloworld.c
Again.. DO SEPARATE the COMPILATION and the LINKING steps!!!
These are common error messages that spawn from the above command...
Exception in thread "main" java.lang.UnsatisfiedLinkError: no helloworld in java.library.path (missing javavm definition)
Exception in thread "main" java.lang.UnsatisfiedLinkError: no suitable image found. Did find: ... mach-o, but wrong architecture (ironically, not really caused by wrong architecture)
Exception in thread "main" java.lang.UnsatisfiedLinkError: no suitable image found. Did find: ... can't map (happens when you use wrong architecture)
ld: library not found for -l..., collect2: ld returned 1 exit status
Undefined symbols: "_main", referenced from: start in crt1.10.6.o, ld: symbol(s) not found, collect2: ld returned 1 exit status
Subscribe to:
Posts (Atom)