Fix Bug625: StructAccessor missing setShortsAt() and getShortsAt() methods for short[]
For short[] Java code gets emitted for an StructAccessor object that uses: void setShortsAt(int i, short[] shorts) short[] getShortsAt(int i, short[] shorts)
Problem was that StructAccessor.java had no such methods - added.
Buffer.isDirect() operation is undefined w/ Eclipse ecj and GCJ gij JRE.
Fix for the runtime error using GCJ gij JRE: java.lang.NoSuchMethodError: method java.nio.Buffer.isDirect with signature ()Z was not found. at com.jogamp.common.nio.Buffers.isDirect(Buffers.java:363)
Also Eclipse ecj refuses to compile code using java.nio.Buffer.isDirect(). ---------- 1. ERROR ... return ((Buffer) buf).isDirect(); ^^^^^^^^ The method isDirect() is undefined for the type Buffer
Modified Java 1.5 Buffers patch 2b7d1b1d25cb2cd73311ec9159b465f0391bf5e0 - May break GCJ/ECJ .. needs to be revised.
- Adding JAVA_6 in PlatformPropsImpl - Buffers.isDirect() chooses fast-path iff JAVA_6, otherwise using reflection (GCJ/ECJ) - Adding JAVA_6 info in VersionUtil - API doc: Refine JAVA_SE and JAVA_6 spec.
TODO: In case GCJ etc is unable to compile the JAVA_6 code even though it uses a static condition (probably not), We have to wrap isStatic in an own class, one for JAVA_6 and one for <= 1.5. This will be a good exercise for further issues we may have w/ Java <= 1.5.
- NativeLibrary Fix - enumerateLibraryPaths(..): - Properly iterate through all prefix _and_ suffix. - Make public for JNILibLoaderBase.loadLibraryInternal(..)
- isValidNativeLibraryName(..): - Stop iterating through prefix, if previously found but suffix doesn't match.
- JNILibLoaderBase.loadLibraryInternal(..) Enhancement - Mark customLibLoader FIXME: remove (we will get rid of jnlp.launcher.class)
- If System.load(TempJarCache) and System.loadLibrary(plainLibName) fails, use NativeLibrary.enumerateLibraryPaths() w/ System.load(..) as last resort.
Tested on Linux x86_64 Java6 and OSX Java7 manually, no regressions expected.
Semantics Change: ExtendedInterfaceSymbolsOnly was used for implementation generation only, which is considered a bug!
- ExtendedInterfaceSymbolsIgnore C.java - Ignore symbols in C.java for interface generation - ExtendedInterfaceSymbolsOnly C.java - Only use symbols in C.java for interface generation - ExtendedImplementationSymbolsIgnore C.java - Ignore symbols in C.java for implementation generation - ExtendedImplementationSymbolsOnly C.java - Only use symbols in C.java for implementation generation - ExtendedIntfAndImplSymbolsIgnore C.java - Ignore symbols in C.java for interface and implementation generation - ExtendedIntfAndImplSymbolsOnly C.java - Only use symbols in C.java for interface and implementation generation
Android: Cleanup ClassLoaderUtil/LauncherUtil - Using cached parent ClassLoader for SYS-Packages w/ native libs, and non cached child ClassLoader for USR-Packages
Android's Dalvik VM, like a JVM, cannot load a native library from one location by multiple ClassLoader.
Since we don't like to hardcode the system-packages, as it was before, i.e. "com.jogamp.common", "javax.media.opengl", we need to either copy the libs or use parenting of cached ClassLoader. The latter is chosen, since it's faster and uses less resources.
- System-packages are passed through from the user 'List<String> LauncherUtil.BaseActivityLauncher::getSysPackages()' to the ActivityLauncher, which instantiates the ClassLoader.
- No more hard-reference the system-packages in ClassLoaderUtil ("com.jogamp.common", "javax.media.opengl"), just use the new user provided system-packages.
- The system-packages denominate a hash-key for caching, a new ClassLoader is created and mapped if it does not yet exist.
- A non-chached user-packages ClassLoader is created using the cached system-packages ClassLoader as it's parent.
Bug 681: Add Basic ELF Header + ARM EABI Section Parsing, allowing to distinguish ARM soft-float/hard-float (part-1)
https://jogamp.org/bugzilla/show_bug.cgi?id=681
+ * References: + * <ul> + * <li>http://linux.die.net/man/5/elf</li> + * <li>http://www.sco.com/developers/gabi/latest/contents.html</li> + * <li>http://infocenter.arm.com/ + * <ul> + * <li>ARM IHI 0044E, current through ABI release 2.09</li> + * <li>ARM IHI 0045D, current through ABI release 2.09</li> + * </ul></li>
Added self contained jogamp.common.os.elf package w/ entry point class ElfHeader to read a RandomAccessFile and parse it as an ELF file.
ELF Parsing completness: - Header: OK - SectionHeader: OK - Section Type SHT_ARM_ATTRIBUTES: OK - Will be read into SectionArmAttributes - Used to distinguisgh soft/hard VFP float
Tested manually on: - Linux intel 32bit / 64bit, arm soft-float and hard-float
Bug 681: Add Elf Parsing for other OS than Linux, if ARM and !ANDROID using /proc/self/exe (Linux) or a found java/jvm native lib.
- PlatformPropsImpl.queryABITypeImpl: Check Elf Header for ARM + !ANDROID (i.e. add other OS than Linux, use native java/jmv lib) - NativeLibrary.enumerateLibraryPaths: Add 'sun.boot.library.path' to enumeration! - TestElfReader01: Add test for finding java/jvm native lib and parse it
Added the ability for users to set a "resolver" in JarUtil that lets it find resources that are loaded by a custom classloader. This is needed in OSGi apps (like Eclipse RCP apps), since OSGi resources do not have simple jar: URLs (they use a custom protocol called bundleresource:).
Adding Function and FunctionTask extending RunnableTask functionality
Function allows passing arguments and having a return value in contrast to Runnable, where FunctionTask allows a Function to be invoked and waited for.
OSX/Java7 darwin/jawt_md.h Workaround ; Disable OSX/i386 if compiled w/ Java7 [1.7 - 2.0]; Valid Java range [1.6 - 2.0].
- OSX/Java7 darwin/jawt_md.h Workaround Include JOGL's JNI MacOSX platform headers, since Oracle's Java7 darwin/jawt_md.h has X11 dependencies and does not define JAWT_SurfaceLayers.
- Disable OSX/i386 if compiled w/ Java7 [1.7 - 2.0] Set macosx32 depending on 'ant.java.version'
- Valid Java range [1.6 - 2.0] Foresee new Java versions 1.9 and 2.0 :)
Load libs and init JNI binding statically w/ @BeforeClass, since OSX/Java7 for some reason gets confused (?) w/ init sequence. This is no issue for JOGL etc .. as far we have observed.