| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
'android-armv7hf' and 'linux-armv7hf' ]
- Platform gets new ABIType [ GENERIC, ARMEL, ARMHF ]
- Platform impl. needs to guess ABIType in case of ARM,
since no Java system property ('os.arch' ..) reflects the new EABI.
I consider this a bug, since this will also hinder JNLP to work.
The latter also uses 'os.arch' sys property to determine the nativelib resource!
(See Platform.guessABITypeImpl(..) for details how we guess the type.)
- Adding symbolic links to ubuntu's gnueabihf cross tool chain
- Adding armhf crossbuild script
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
PropertyAccess: Fix security code, grant access to common 'trusted' properties
- SecurityUtil
- Generalize cert validation for JAR and property access
- Grant access to common AccessControlContext for 'same' cert
- PropertyAccess:
- Fix security code: Passing the current AccessControlContext from the caller
didn't include priviledges.
- Grant access to common 'trusted' properties,
which removes the need of passing the AccessControlContext for general properties
like 'jnlp.', 'jogamp.' ..
- Enable registering 'trusted' properties, when caller's cert is 'same'
|
| | |
|
| |
|
|
| |
Platform.loadGlueGenRTImpl(), Reuse JarUtil (same methodology) to determine whether we run from JarURL
|
| |
|
|
| |
our lifecycle. JarFile's hash almost always differs.
|
| |
|
|
|
|
|
|
| |
JNILibLoaderBase's 'addNativeJarLibs(Class<?> classFromJavaJar, String allNativeJarBaseName, String[] atomicNativeJarBaseNames)'
now just attempts to load the 'all' variant, and will continue w/ atomics if not successful (ie not available).
It skips the validation of a 'allJavaJarPrefix', ie validating the 'classFromJavaJar holding JAR file,
which allows GLUEGEN/JOGL classes to be contained in JAR files other than the original.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It turns out that Java's File mkdir() only makes the directory writable for the current user,
I have missed this fact. Great catch.
1. Fix TempJarCache.isInitialized(): Return false if not successfully initialized.
It merely returned if it has passed 'initSingleton()' and ignored the staticInitError.
2. Fix TempFileCache pattern of determining the temp base directory
We cannot just use a static directory name, due to the multi user environment
and user write permissions on File.mkdir().
IOUtil has a new 'getTempDir(..)' methods, which iterates through integers [000000-999999]
until a writeable directory could be found or created.
TempFileCache initializes this temp base dir in the static block ensuring
the value is final for the JVM / ClassLoader.
Updated comments/docs in TempFileCache.
|
| |
|
|
|
|
|
|
| |
Add unit test.
Misc.:
- IOUtil: Add toURL* methods
- TempJarCache: Add 'URL getResource(String)'
|
| | |
|
| | |
|
| |
|
|
| |
Certificates if caller has any. Add Convenient JNILibLoaderBase.addNativeJarLibs(..) method.
|
| |
|
|
|
|
| |
- JNILibLoaderBase: If TempJarCache is active, try find native library in cached JARs
- TempJarCache: Add bootstrabNativeLib(..) allowing bootstraping gluegen-rt from JAR w/o needing it
- JARUtil: minor edits (final)
|
| |
|
|
| |
initialization/usage only
|
|
|
JarUtil:
Utility to handle Jar files and it's content, incl. extracting it's entries
TempFileCache:
Utility to have a save temporary file cache per JVM and per instance,
eg. per ClassLoader.
The temp cache is cleaned up with the next usage of TempFileCache,
which solves the troubles of JVM bugs and situations where the JVM
is not able to close and delete open temp files.
TempJarCache:
Utility to cache Jar files temporary (using TempFileCache)
and access it's content.
This class is suitable to implement a URLClassLoader
or similar resource loading facilities.
All tested w/ TestTempJarCache
|
