| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
+ Fix JLS Binary Compat: Moving methods and fields upwards for classes _and_ interfaces is OK
+
+ - We shall also travers all interfaces upwards
+ - All methods and fields found upwards must be tested for compatibility as well!
+
+ Further:
+ - Add class-name to Field- and MethodInfo via new intermediate AbstractMemberInfo.
+ The class-name is used to have allow differs to find a class move upwards!
+
+ - Pretty printing of class move binary-compatible change
|
|
|
|
| |
and API doc)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Uri to handle relative path
Fix IOUtil.cleanPathString(..) special case:
Special case '/a/./../b' -> '/b'
requires to resolve './' before '../'.
Allow IOUtil and Uri to handle relative path:
- IOUtil.getParentOf(..)
- IOUtil.cleanPathString(..)
Handle cases:
'a/./../b' -> 'b'
'.././b' -> '../b'
- Uri: Handle null scheme
|
|
|
|
| |
Messages
|
|
|
|
|
|
|
|
|
|
|
|
| |
caller to skip relative futile lookup
IOUtil.getResource(..) and IOUtil.ClassResources, needs more clarity.
ClassLoader shall be passed explicitly next to the optional
relative context Class instance.
This allows better efficiency, i.e. caller can pass ClassLoader
but skip a possible relative lookup, if not existing.
|
|
|
|
| |
deflated files w/ zip-level 9
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
test-executable ; Use CustomInflate for Performance
- Use 'WinMain' for Windows test-executable
This may have little difference than using std 'main' entry
- Add Windows x86_64 test executable
Since the reporter claims the test executable works well
on Windows i386, maybe utilizing a x86_64 test executable
on same VM fixes the issue
- Use CustomInflate for Performance
- Skips GZIP header
- Adds own custom header [magic, deflate-size, inflate-size]
- Own header allows simplified I/O read and deflation
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ensure launched native exe process terminates.
See Bug 1219 comment 58: It seems that on some Windows platforms
the launched native process using our test-exe keeps running
even though we issued Process.waitFor().
Hence we issue Process.destroy() in the finalize block
to at least attempt to terminate it.
Note: The Process implementation is platform specific and may vary.
|
|
|
|
|
|
|
|
|
| |
hardcoded 'DEBUG_EXE_EXISTING_FILE = false'
This is required for security, i.e. not allowing to execute any pre-existing files!
In case we need to manually debug this issue,
we can re-enable it manually and locally, but not in public builds!
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Make StreamMonitor a daemon thread, i.e. not hindering VM from exit
- Earmark each InputStream's EOS state
and only attempt to readByte if !eos
- End loop and hence the thread if all InputStream
have reached EOS.
- Don't close the InputStream.
Closing the InputStream is expected to be done
by the owner, otherwise no EOS could even be reached!
- Flush the output PrintStream at thread exit
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
IOUtil.testDirExe():
- Satisfactory when executed
Failure to execute produce an IOException right at ProcessBuilder.start().
Hence we can allow an unexpected process exit value,
since we only want to learn whether executable files are allowed.
- More debug options
DEBUG_EXE: 'jogamp.debug.IOUtil.Exe'
DEBUG_EXE_NOSTREAM: 'jogamp.debug.IOUtil.Exe.NoStream'
- if DEBUG_EXE
- a pre-existing 'jogamp_exe_tst'+<SUFFIX> will be used as-is.
- the test-exe will not be deleted
- StreamMonitor is being used to dump stdout/stderr
if !DEBUG_EXE_NOSTREAM.
|
|
|
|
|
|
|
|
|
| |
Previous test PE exe, commit 0ebc5398fa20d23214a37dc4930a1fa1617293c7,
was a console exe. A console exe opens a new console window
if not being launched from one.
New test PE exe is produced w/ '-mwindows', i.e. for Win32 API
w/o a console.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Windows using 'exe-windows-i586-268b.bin' (Fix attempt #1)
Replacing the tiny 268 byte sized 'exe-windows-i586-268b.bin' PE file
w/ a regular 2048 byte sized PE file 'exe-windows-i386-2048b.bin'.
File is produced via:
c:\mingw\bin\gcc -nodefaultlibs -nostdlib -s -Os -o tiny.exe tiny.c
Adding the 305 byte sized gzipped version 'exe-windows-i386-2048b.bin.305b.gz'
to the gluegen-rt jar file to reduce the payload for non Windows platforms.
Adding special property 'jogamp.debug.IOUtil.Exe' to debug testing the exe file,
enable via '-Djogamp.debug.IOUtil.Exe'.
Passes here on all Windows machines, however, the prev. one worked here as well.
|
|
|
|
|
|
| |
GlueGen'w runtime dependency com.jogamp.common.util.InterruptSource
was introduced in commit 1c4e2d3ea379fe6578dfb84e10f22729b71b1ae5
but the launcher loads the same ..
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Use InterruptSource.Thread.create(..),
while reducing InterruptSource.Thread ctors to 3 variants.
- Use InterruptSource.Thread instead of java.lang.Thread where possible
- Use SourcedInterruptedException where possible
- SingletonInstanceServerSocket: start(), stop() and run()
- Persistent-Wait and Cancelable
- Add @since 2.3.2
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
implementation and semantics
- TaskBase
- requires 'volatile boolean isExecuted' for atomic query of same semantics
- fix isInQueue(): condition was reverse in regars to 'isExecuted'
- expose 'Thread getExecutionThread()' as learned within run() method.
- RunnableTask
- deprecate: 'static invoke(final boolean waitUntilDone, final Runnable runnable)',
since it's nonsense, use runnable.run() instead.
- 'static RunnableTask invokeOnNewThread(..)'
- uses InterruptSource.Thread
- Persistent-Wait
- Cancelable using InterruptedRuntimeException
- FunctionTask
- deprecate 'static <U,V> U invoke(final boolean waitUntilDone, final Function<U,V> func, final V... args)',
since it's nonsense, use func.eval(args) instead.
- 'static FunctionTask<U,V> invokeOnNewThread(..)'
- uses InterruptSource.Thread
- Persistent-Wait
- Cancelable using InterruptedRuntimeException
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
InterruptedRuntimeException
- InterruptSource interface declares methods to retrieve
the source of a Thread.interrupt() call.
- InterruptSource.Thread implements InterruptSource,
i.e. allows code running within such thread to learn about
the interrupt source (stack trace).
- SourcedInterruptedException is a InterruptedException specialization
which may include the source of the causing Thread.interrupt() call.
- InterruptedRuntimeException
An unchecked RuntimeException propagating an InterruptedException
where handling of the latter is not desired.
The causing InterruptedException may be of type SourcedInterruptedException,
hence a detailed stack trace analysis might be possible.
|
|
|
|
| |
test cases to run concurrently
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
interrupts original-owner, even if not waiting at unlock()
RecursiveThreadGroupLockImpl01Unfairish.unlock():
An interrupt() is always issued
from group members on the original owner.
This shall only happen, if the original owner is waiting
within unlock() for all group members to be unlocked.
This extra interrupt causes side-effects, see Bug 1211.
Only issue the interrupt to wake-up the original owner
iff waiting within unlock!
+++
RecursiveLockImpl01CompleteFair:
Issue 'Thread.interrupted()' to clear a slipped interrupt
call after while-loop.
|
| |
|
|
|
|
| |
IllegalArgumentException exceptions
|
|
|
|
| |
'jogamp.debug.JNILibLoader.Perf'
|
|
|
|
|
|
|
| |
single-slim-jar, #2 fat-jar, #3 Classpath + TAG.class
We shall attempt the official recommendation of deployment first (single-slim-jar)
not wasting time trying a 'nativeLibraryPath' lookup within the classpath.
|
|
|
|
|
|
|
|
| |
'natives/os.and.arch', reducing JAR search.
Since all native libraries are now contained within 'natives/os.and.arch',
we don't need to search the whole JAR file anymore
but simply can copy the content of the defined folder - if existing.
|
|
|
|
|
|
|
|
| |
In case we run fat-jar file, the package name is 'com.jogamp'
and all entries are based upon GlueGen.
JogampVersion will fall back trying to find a fat-jar Manifest
in case a null Manifest is being passed.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
PlatformPropsImpl.findSysLib(..).
This patch partially reverts of commit d12e4d4ea279998b27457691038e709879dcaca6.
NativeLibrary.open(..) requires search of system libraries,
since it loads the actual 'tool library' for which we generate the JNI binding.
The 'tool library' is preferably the system wide installed version,
e.g. libGL.so etc.
PlatformPropsImpl.findSysLib(..) also requires finding system libraries
as needed for PlatformPropsImpl.queryElfFile(..), i.e. using libjava.so etc.
Only the JNI 'glue library', glueing java calls to the 'tool library',
shall not use the system wide library search since we shall only use
JogAmp provided instances here.
This patch also reinstates binary compatibility w/ prev. GlueGen JARs
since NativeLibrary.enumerateLibraryPath(..) is public.
+++
Further more 'NativeLibrary.enumerateLibraryPath(..)'
now adds OSX system framework search _before_ the user path
in case 'searchSystemPath && searchSystemPathFirst'.
Original code always added this search to the end,
which does not match the intended behavior (-> bug).
|
|\
| |
| |
| |
| |
| |
| | |
Conflicts:
src/java/com/jogamp/common/os/NativeLibrary.java
Due to commit for Bug 1145, bf4d8786cb732d86db333b43020ecf0af27f60bf
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
extension mechanism
NativeLibrary:
API change: Removed searchSystemPathFirst argument to the
open and enumerateLibraryPaths methods.
Removed the generic sun.boot.library.path system path and the
MacOS specific Frameworks paths from enumerateLibraryPaths.
JNILibLoaderBase, PlatformPropsImpl & TestElfReader01:
Updated to handle the NativeLibrary API change.
This change will prevent JogAmp modules to pickup and load unsupported
and old SUN JOGL 1 natives that may have been deployed with the JRE.
|
|\ \ |
|
| |/
| |
| |
| |
| |
| | |
natives/os-arch/ + library names
Fixes Bug 1145 cc1 when using an unpacked fat-jar
|
|/ |
|
|
|
|
| |
of put32/get32
|
|
|
|
|
|
|
| |
'toolGetProcAddressHandle' (Bug 1062)
Show 'toolGetProcAddressHandle' in DEBUG mode in DynamicLibraryBundle.toolDynamicLookupFunction(..),
allowing to validate source of symbols.
|
| |
|
| |
|
| |
|
|
|
|
| |
unit)
|
|
|
|
| |
and bitCount(), add unit test (passed)
|
| |
|
|
|
|
| |
synchronized delegation; TODO: Unit tests.
|
| |
|
|
|
|
| |
ArrayIndexOutOfBoundsException
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
IntBitfield
IntBitfield's 64bit bit-size is exceeding its use-case,
making it less efficient and complicated.
Bitfield offers a fast path implementation for 32 bits
as well as a int[] implementation.
TODO: 32 bit Unaligned putInt32(..) and getInt32(..),
currently throwing UnsupportedOperationException for int[] impl.
|
| |
|
|
|
|
|
|
|
|
| |
New distributed files in 'dist' subfolder for producing fat files via jogamp-scripting:
dist/jogamp-fat.mf
dist/jogamp-test-fat.mf
dist/junit.jar
|
| |
|