| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
| |
(segment) of the input stream (skipBytes, byteCount)
This method is inspired by Bug 1280, <https://github.com/sgothel/joal/pull/16>,
'copy only needed bytes' for JOAL's com.jogamp.openal.util.WAVData.loadFromStream(..).
This method is a revised version of the proposed IOHelpers.copyFromStream2ByteBuffer(..),
see <https://github.com/OndrejSpanel/joal/commit/1616659e98904270af4faca25b770d0983609735>
|
|
|
|
| |
'totalNumBytes' argument, since we have no user-feedback callback passed.
|
| |
|
| |
|
|
|
|
| |
'const' qualifier
|
|
|
|
| |
'yield_thread()' to avoid potential Java>17 collision (JEP 361)
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Test1p1Test1p1JavaEmitter
'com.jogamp.gluegen.test.junit.generation.Test1p1JavaEmitter' exposes a regression
using MingW64 8.1.0: System.loadLibrary() gives a "Can't find dependent libraries".
Here, 'Bindingtest1p1' is linked against 'test1' and fails to load
due to its wrong dependent library name within 'Bindingtest1p1'.
MingW64 8.1.0 dropped 'libtest1.so' into 'Bindingtest1p1.dll',
which is surely wrong. Even passing '-Wl,-soname=test1.dll' didn't help.
Note: Such constellation would only work with adding
the lib-path to PATH on Windows.
Since we don't utilize the method in any of our projects,
but use the dynamic library lookup method - this is not a blocker,
but wasted some good time.
|
|
|
|
|
|
|
|
|
|
|
| |
As of Java9, sun.misc.Cleaner has moved to jdk.internal.ref.Cleaner.
However, access has been made (under the table) via sun.misc.Unsafe,
which we are using for now as we cannot set the jdk.internal.ref.Cleaner method accessible.
In this regard, we had to change our Cleaner.clean(..) method using a ByteBuffer
instead of a Buffer object paramter.
All tests have passed, no more illegal access case running on Java11 has been exposed.
|
|
|
|
|
|
|
|
|
|
| |
gluegen-rt -> gluegen_rt
- Fix finding native library for Elf parsing
- Fix one unit test
- Fix comments
Completes commit 330dad069dee5a0cc0480cf5cd9052000004223a
|
|
|
|
|
|
|
|
|
| |
When annotations were placed on dummy Java variables, the annotation
processor was emitting a RenameJavaType directive into the gluegen
config file that caused the emitted file to be named boolean.java
instead of RenderingConfig.java or Pixel.java. Turned off this behavior
when jname is given in the @CStruct annotation. I'm uncertain how much
this processor is even used, since I can't find any occurrences of
@CStruct outside the test code for it in gluegen.
|
|
|
|
|
| |
Implementation currently uses 256 bit Secure Hash (SHA) algorithm, but this may change in the future.
Hence only use 'SHA' in the names, not 'SHA256'.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
runtime validation
This change implements a strong SHA256 signature over:
1) source tree inclusive make recipe (SHA256-Source)
2) all class files (SHA256-Classes)
3) all native libraries (SHA256-Natives)
4) the class files as deployed in the jar (SHA256-Classes-this)
5) the native libraries as deployed in the jar (SHA256-Natives-this)
and drops all of these in the deployed Jar file.
This allows SHA256 validation of (4) + (5) at runtime
and further complete validation (1), (2) and (3) offline.
Full SCC would now required (1) - (3) to be placed on a server for further validation.
Optionally we may use GPG <https://gnupg.org/> or PGP to validate the build entity to implement the chain of trust <https://en.wikipedia.org/wiki/Chain_of_trust>
The SHA256 runtime validation is tested via: com.jogamp.common.util.TestVersionInfo
|
|
|
|
| |
executables
|
|
|
|
| |
for System related Operations
|
|
|
|
|
|
|
|
|
|
|
| |
and 'searchSystemPathFirst' attributes
NativeLibrary can be instantiate by defining
'searchSystemPath' and 'searchSystemPathFirst' arguments,
allowing to specify the system path role while looking up the library.
Since NativeLibrary is utilized via DynamicLibraryBundleInfo upstream,
the latter interface shall allow users to specify those attributes.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- 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
|
|
|
|
| |
test cases to run concurrently
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
of put32/get32
|
| |
|
| |
|
|
|
|
| |
and bitCount(), add unit test (passed)
|
| |
|
| |
|
|
|
|
| |
tests
|
|
|
|
| |
Signed-off-by: Xerxes Rånby <[email protected]>
|
|
|
|
| |
CompatibilityType.BACKWARD_COMPATIBLE_BINARY
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
java space, incl. [native] numbers
Rewrite ConstantDefinition:
Add sub-class CNumber:
- containing integer/float values and their original qualifiers
[long, double, unsigned]
- conversion to java number
ConstantDefinition:
- holds native expression
- optionally holds CNumber representing native expression,
if [only] a number
- can compute equivalent java expression
with result type (JavaExpr)
Add static native number reg-expression
for number detection and parsing.
Add static native number to CNumber conversion methods.
+++
Retrieve full LISP tree and convert to serialized expression
to be utilized for expressions used in enumerates.
Parse enumerates, allowing const native expressions:
- Utilize ConstantDefinition
either for definite CNumber or expression
- Simply add "+1" for new default values,
if previous is an expression
|
|
|
|
|
|
| |
ArrayHashMap; Unify ctor for both impl.
Add/Enhance unit tests for both.
|
|
|
|
| |
-> v23x
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
regexp-constant and java-parser. (Due to PCPP -> JCPP)
Lack of parsing binary exponent floats is exposed due to using JCPP
and correct constant-definitions.
- JavaParser.g:
- Add support for hexadecimal w/ binary exponent floats
- TAB -> 4 spaces
- ConstantDefinition.java:
- Add RegExp 'fpRegexp', patternDecimalNumber:
decimal number w/ support for hexadecimal w/ binary exponent floats.
- isDecimalNumber(..): Use patternDecimalNumber
instead of try-and-error (NumberFormatException)
- patternCPPOperand: exclude patternDecimalNumber!
- JavaEmitter.java:
- Respect explicit suffix [dD] for double type.
- Drop floating point suffixes [fF]
- Test: Added tests for hexadecimal w/ binary exponent floats
|
|
|
|
| |
JCPP submodule, build, test and doc)
|
|
|
|
| |
Cleanup / Preparation)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
renamed original
'DelegateImplementation' is a variation of 'ManuallyImplement'.
'ManuallyImplement' emits the interface method, but suppresses
the Java and native-code implementation.
The latter shall be implemented manually by the user.
'DelegateImplementation' emits the interface method,
and the _private_ renamed Java and native-code implementation.
Both can be called from the manual user implementation,
hence delegation.
Configuration:
DelegateImplementation <ORIG-SYMBOL> <RENAMED-IMPL-SYMBOL>
I.e. delegation model shall apply to <ORIG-SYMBOL>
and the Java and native-code implementation renamed to <RENAMED-IMPL-SYMBOL>.
The user manual implementation of <ORIG-SYMBOL>
may delegate to <RENAMED-IMPL-SYMBOL>.
|
|
|
|
| |
(Expose source location for log/error messages)
|