JNAerator 0.12 released: a year’s worth of fixes and improvements!

JNAerator (licensed under LGPL 3.0) lets Java programmers access native libraries transparently, using a runtime such as BridJ (C / C++, BSD-license), JNA (C only, LGPL) or Rococoa (Objective-C), and now Node.js!

This release took a while longer than usual, but JNAerator’s moving to its own GitHub repo with Travis integration and all, hopefully making contributions easier :-).

The 0.12 release can be downloaded here, and here are its release notes (see full CHANGELOG):

  • Added -library foo -dependencies bar,baz to generate @Library("foo", dependencies = {"bar", "baz"})(issue nativelibs4java#535)
  • Added JNA-only -forceStringSignatures option to force String and String[] params even with char* and char** (as opposed to const char* and const char**) (issue nativelibs4java#476)
  • Added -skipDeprecated option for JNA output (issue nativelibs4java#480)
  • Added -forceNames option to issue Name annotations for all supported entities (issue nativelibs4java#443)
  • Added @Name support to all entities (issue nativelibs4java#443)
  • Added partial support for C++ namespaces with GCC-compiled libraries (issue nativelibs4java#446)
  • Added a new “peer pointer” constructor to JNA structures (issue nativelibs4java#442, thanks to topikachu@ for the patch!)
  • Added -publicRawBindings and -noRawBindings options (since -genRawBindings is now the default)
  • Added support for JNA 4.0.0 (implement getFieldOrder in all structs, see issue nativelibs4java#384)
  • Added support for node.js target runtime (see example of bindings: https://github.com/ochafik/node-opencl)
  • Added -optionalFunctions option to tag functions with @org.bridj.ann.Optional
  • Added mechanism to skip generation of entities (-skipStructs, -skipEnums, -skipFunctions)
  • Added -noStaticInit option for BridJ
  • Added -extractDeclarations option to create an interface with all the methods and types of a library (BridJ-specific)
  • Improved harvesting of header comments: go further away before the declaration, and remove leading * in oxygen comment lines (issue nativelibs4java#481)
  • Improved raw mode for BridJ callbacks: in raw mode, generate two crossed callbacks, one of which must be overridden.
  • Reverted to by-default chunks parsing, and added -parseInOnePiece instead of -parseChunks (makes parsing more robust to syntax errors)
  • Moved to ECJ 4.2.2
  • Dropped support for bit fields in JNA structs (users should implement bit manipulation logic manually or use BridJ: JNAerator’s fork of JNA that added this feature incurred too much maintenance work).
  • Dropped old shared library (DLL, Mach-O) scanning code, superseded by dyncall/dynload and BridJ’s demanglers.
  • Fixed missing actual name in raw native methods (issue nativelibs4java#499, thanks to @washley for the patch!)
  • Fixed handling of const char * const * params for JNA runtime (issue nativelibs4java#476)
  • Fixed duplicate bindings with -reification, caused by interaction with interface extraction feature (issue nativelibs4java#500)
  • Fixed duplicate & mismatching @Name annotations with -beautifyNames (issue nativelibs4java#460)
  • Fixed routing of simple callback with ptr-ptr arg (e.g. typedef void* (*F3)(int** pptr))
  • Fixed pointer casts in constants (issue nativelibs4java#132)
  • Fixed some GLib parsing issues: type literals of null TypeRefs, support signatures with va_list / __gnuc_va_list and __builtin_va_list, and fixed NPE (issue nativelibs4java#132)
  • Fixed parsing of exotic enums (issue nativelibs4java#459)
  • Fixed parsing of many Objective-C (property) attributes
  • Fixed case-sensitivity of C/C++ modifiers, which prevented some variables from being parsed (issue nativelibs4java#449)
  • Fixed parsing of unsigned long constants (issue nativelibs4java#362, issue nativelibs4java#374)
  • Fixed generation of raw bindings for callback return types (issue nativelibs4java#386)
  • Fixed generation of raw bindings with varargs (issue nativelibs4java#386, patch contributed by twitwi!)
  • Fixed generation of pointer to fake pointer for JNA target (issue nativelibs4java#403)
  • Fixed handling of library names with hyphens (issue nativelibs4java#260)
  • Fixed support of identifiers with Object method names (issue nativelibs4java#375)
  • Fixed support of enums inside objc classes (issue nativelibs4java#370)
  • Fixed parsing of @optional and @required objective-c annotations (issue nativelibs4java#369)
  • Fixed UTF32Char, added VOID, CHAR and byte as predefined types (issue nativelibs4java#363)
  • Fixed silent disappearance of struct field conversion errors (issue nativelibs4java#390)
  • Fixed pom files for Maven output modes (removed rococoa dependency by default, added commented repo needed by it)
  • Fixed resolution of typedef’d structs when the typedef name was chosen as “better” than the original struct tag (issue nativelibs4java#367)
  • Fixed restitution of hex constants (issue nativelibs4java#362)
  • Fixed parsing of restrict args
  • Fixed parsing of MinGW system headers (issue nativelibs4java#373)
  • Fixed wrong use of stdcall mapper outside Windows in JNAerator Runtime
  • Fixed recursive typedefs
  • Fixed typedefs of forward-declared enums and structs (issue nativelibs4java#430)
  • Fixed handling of large unicode values (issue nativelibs4java#401)
  • Fixed warnings for getFieldOrder (issue nativelibs4java#408)
  • Fixed handling of constant array sizes that depend on enums for BridJ (issue nativelibs4java#354)
  • Fixed handling of hypens in package names (issue nativelibs4java#260)
  • Fixed OSGi imports (issue nativelibs4java#429, thanks to Michael Werle for the pull request!) …

Special thanks to the users and bug reporters that helped getting this version out !

You can contribute to the project by reporting bugs here and joining the NativeLibs4Java Community.

Posted in JNAerator, Uncategorized | Comments Off

BridJ 0.7.0 released: experimental Android & RPi support, tons of fixes!

BridJ (BSD-licensed) is an innovative native bindings library that lets Java programmers use native libraries (written in C, C++, ObjectiveC and more) in a very natural way (inspired by the great JNA, with better performance, C++ and generics added).

Huge thanks to BridJ’s contributors and bug reporters who made that version possible!

Here’s a summary of the changes since version 0.6.2 (see full CHANGELOG):

  • Added LRU pointer cache (disable with -Dbridj.cache.pointers=false or BRIDJ_CACHE_POINTERS=0), which helps keep short-lived pointer garbage to a minimum for some use cases (see issue nativelibs4java#440)
  • Added experimental support for Raspberry Pi (Linux/armhf, hard-float ABI).
  • Added a new all-in-one android release zip with classes JAR (now contains no native lib), native libs, sources & javadoc.
  • Added programmatic setting of library dependencies: BridJ.addNativeLibraryDependencies (issue nativelibs4java#424), -Dbridj.Xyz.dependencies=Abc,Def and BRIDJ_XYZ_DEPENDENCIES=Abc,Def (issue #391)
  • Added a very useful BRIDJ_DEBUG_POINTER_RELEASES=1 / -Dbridj.debug.pointer.releases=true mode that helps track double releases (also enabled when BRIDJ_DEBUG_POINTERS=1 / -Dbridj.debug.pointers=true).
  • Added Pointer.pointerToAddress(peer, size, io, release)
  • Added fallback to GCC demangler for mingw32 on Windows (issue nativelibs4java#356).
  • Added support for exact library file name (issue nativelibs4java#424)
  • Added Pointer.pointerTo(IntValuedEnum<E>) (issue nativelibs4java#414)
  • Added support for C++ namespaces (issue nativelibs4java#446)
  • Added support for @Name annotations on structs and enums (allows refactoring of such classes, issue nativelibs4java#443)
  • Added support for new JNAerator-generated crossed callbacks (one with an object-heavy signature, and one with raw types, each calling the other, one of the two being overridden)
  • Dropped C# runtime stubs
  • Dropped linux-only and mac-only packages.
  • Improved performance of all operations of Pointers with bounds (~ 25% faster).
  • Improved concurrency of callbacks and structs creation.
  • Improved logs (issue nativelibs4java#328, issue nativelibs4java#346).
  • Improved C++ templates (still WIP, std::list protoype and fixed std::vector)
  • Improved Grails integration with Platform.getClassLoader change (issue nativelibs4java#431)
  • Improved PointerIO caching.
  • Refactored StructIO (split out description of struct and its fields as top-level entities, StructIO now just does IO). This is what justifies version bump.
  • Rebuilt Linux binaries with –hash-style=both for better backwards compatibility (issue nativelibs4java#436)
  • Rebuilt Linux binaries with -z noexecstack
  • Rebuilt Unix libraries with -fno-stack-protector, and force GLIBC dependency down to 2.3.4 (issue nativelibs4java#467)
  • Rebuilt Solaris binaries with statically linked libgcc (issue nativelibs4java#452)
  • Fixed C++ demangling of int vs. pointer (issue nativelibs4java#482)
  • Fixed bit fields in structs! (issue nativelibs4java#496)
  • Fixed Windows c library alias: “msvcrt”, not “mscvrt” (issue nativelibs4java#492, thanks to @rkraneis for the patch!)
  • Fixed multithreading crashes due to strerror (issue nativelibs4java#450)
  • Fixed @Alignment annotation
  • Fixed demangling of pointer types (now stricter matching of target types, with support for callbacks).
  • Fixed support for Android/arm: artifact of last two releases lacked the binary, and had to move android libs from lib/ to libs/ (issue nativelibs4java#382)
  • Fixed usage of local refs in getLibrarySymbols to avoid reaching Dalvik’s limit (issue nativelibs4java#376)
  • Fixed openjdk library path (take it from sun.boot.library.path)
  • Fixed VARIANT memory management: use VariantInit and VariantClear + allocate it (and other structs tagged with COMRuntime) with CoTaskMemAlloc (see issue nativelibs4java#389)
  • Fixed typo in EllipsisHelper that broke some varargs
  • Fixed loading of dependent libraries on Windows using LoadLibraryEx + LOAD_WITH_ALTERED_PATH (issue nativelibs4java#378)
  • Fixed binding of c library on windows
  • Fixed pointerToCStrings: don’t update string array (might be causing / aggravating #397)
  • Fixed native library lookup logic (issue nativelibs4java#406)
  • Fixed NPE in DefaultParameterizedType.hashCode (issue nativelibs4java#411)
  • Fixed handling of @Name when demangler goes nuts (issue nativelibs4java#413)
  • Fixed FlagSet.toString() and had FlagSet.fromValue(int, E[]) to return raw enum when possible instead of always a FlagSet (issue nativelibs4java#414)
  • Fixed alignment on 32-bit linux (issue nativelibs4java#320)
  • Fixed warnings about missing vtables for COM objects (issue nativelibs4java#355)
  • Fixed disappearing MFC & STL classes in artifacts (issue nativelibs4java#392)
  • Fixed some GCC demangling shortcut cases like repeated const pointers.
  • Documented effects of protected mode (issue nativelibs4java#394)
  • Documented DefaultParameterizedType.paramType (see issue nativelibs4java#418) …

Special thanks to the users, contributors and bug reporters that helped getting this version out !

You can contribute to the project by reporting bugs here and joining the NativeLibs4Java Community.

Wait no longer : download and use BridJ now !

Posted in BridJ | Comments Off

JavaCL 1.0.0-RC4: bugfixes + partial support for OpenCL 1.2

JavaCL v1.0.0 RC4 is available!

Download / Install | Browse JavaDoc | Getting Started (Tutorial) | Discuss

JavaCL is a BSD-licensed library that provides object-oriented OpenCL bindings for Java, helping run massively-parallel computations on graphic cards (and/or CPUs).

The project is migrating to its own GitHub repository, where all new issues should be filed.

Release Notes

Here are the changes between 1.0.0-RC3 and 1.0.0-RC4 (see full CHANGELOG) :

  • Dropped Blas artifact from main deployment (requires addional repo since ujmp is not in Maven Central)
  • Dropped support for JNA variant of JavaCL. Migration is highly encouraged to get more features and bugfixes: https://code.google.com/p/javacl/wiki/MigratingFromJNAToBridJ
  • Updated to BridJ 0.7 (brings fixes and lots of performance enhancements)
  • Optimized allocation of native memory throughout the library (reusing thread-local pointer pools)
  • Optimized (CLDevice, CLPlatform).hasExtension
  • Added basic handling of structs in JavaCL Generator (issue nativelibs4java#421, issue nativelibs4java#422, issue nativelibs4java#423)
  • Added CLBuffer.copyTo, .copyBytesTo, .copyElementsTo
  • Added CLBuffer.fillBuffer to support OpenCL 1.2 clEnqueueFillBuffer (issue nativelibs4java#232)
  • Added CLDevice.getParent()
  • Added CLDevice.getPrintfBufferSize(), .isPreferredInteropUserSync(), .isLinkerAvailable()
  • Added CLImage.copyTo (issue nativelibs4java#508)
  • Added CLImage.fillImage (issue nativelibs4java#232)
  • Added CLPlatform.unloadPlatformCompiler() with automatic switch between OpenCL 1.1 clUnloadCompiler and OpenCL 1.2 clUnloadPlatformCompiler (issue nativelibs4java#232)
  • Added CLQueue.enqueueBarrier & .enqueueMarker to support clEnqueueBarrierWithWaitList & clEnqueueMarkerWithWaitList (switching between OpenCL 1.1 and OpenCL 1.2 variants automatically) (issue nativelibs4java#232)
  • Added CLQueue.enqueueMigrateMemObjects (issue nativelibs4java#232)
  • Added JAVACL_LOG_CALLS=1 / -Djavacl.logCalls=true to log every native call (similar to BRIDJ_LOG_CALLS except it prints the parameter and return values)
  • Added many missing CLDevice 1.2 info getters (issue nativelibs4java#232),
  • Added MapFlags.WriteInvalidateRegion (CL_MAP_WRITE_INVALIDATE_REGION from OpenCL 1.2) (issue nativelibs4java#232)
  • Fixed crash in CLPlatform.getBinaries()
  • Fixed excessive logs for deprecated features and missing OpenCL 1.1 and 1.2 functions (especially if version < deprecatedVersion)
  • Fixed issue nativelibs4java#387: don’t call clReleaseDevice (OpenCL 1.2) unless explicitly needed
  • Fixed issue nativelibs4java#397: crash on Radeon due to bug in driver (attempts to get the source from a program created with clCreateProgramWithBinary yields a segfault)
  • Fixed issue nativelibs4java#397: major bug in CLProgram
  • Fixed issue nativelibs4java#420: horrible random native crash (double release, found with new -Dbridj.debug.pointer.releases=true).
  • Fixed issue nativelibs4java#453: don’t try to load cached binaries for programs created from binaries!
  • Fixed issue nativelibs4java#455: when reading binaries, skip devices that are not allowed
  • Fixed issue nativelibs4java#479: avoid some NPEs in CLProgram.getProgramBuildInfo
  • Fixed typo: CLDevice.getOpenCLVersion -> getOpenCLCVersion



Getting started

You can read the Getting Started (Tutorial) page on the wiki to get started very quickly !

Please join the NativeLibs4Java Google Group to discuss JavaCL, get the latest news and ask for support from the growing JavaCL community.

Posted in Uncategorized | Comments Off

Scalaxy/MacroExtensions: a DSL / compiler plugin to write macro-based DSLs (enrichments without runtime dependency!)

Quick link: Scalaxy/MacroExtensions on GitHub

Scala’s enrich-my-library pattern allows Scala developers to add methods (and more) to existing classes.

Scala 2.10 facilitates this pattern by providing implicit classes:

This works great, but…

  • It usually implies some object creation at runtime (lightweight though it might be, expecially if the extension is a value class),
  • Your extension library is a new runtime dependency (which is not such a bad thing, but it can be avoided, please read on).

The other day, Eric Christiansen rightly complained on NativeLibs4Java’s mailing list that Scalaxy/Compilets were quite constrained by the typer, and that he wished he could define extension methods more easily.

I gave that a serious thought, and came up with a compiler plugin that runs before the typer / namer and performs the following expansion:

Quite exciting syntax twisting, but overall not a huge line-saver.

Then I realized there’s another pattern that could benefit from such rewrites: macros enrichments.

A macro enrichment?

A macro enrichment just extends the “enrich-my-library” pattern by implementing the extension method using a macro. As a result, the enrichment is “inlined” at compilation time, and there’s no runtime dependency nor overhead. See my recent experiments for examples of such macro enrichments:

Scalaxy/MacroExtensions just uses the exact same syntax as above to create all the implicit class / macro wiring necessary to implement the extension as a macro:

Update(Feb 22th 2013): Updated the syntax to use @scalaxy.extend instead of @extend.

The plugin supports two kinds of body for extension methods: regular code, and macro.

  • If the body looks like some regular method implementation, as above, it will wrap it in a reify call and will wrap all references to self and to the method parameters in splice calls.
  • If the body is a macro implementation, it will put it verbatim in the resulting macro:

If you find this cool, just give it a try! (and follow me on Twitter if you want to hear about my next experiments :-)).

Posted in Uncategorized | Comments Off

Scalaxy/Debug: macros that make Predef.assert, require and assume a joy to use!

Quick link: jump to Scalaxy/Debug straight away!

Throughout languages, assertions have proved to be a handy tool for programmers who want “light” error checks for very unlikely error cases (these checks are typically only performed in Debug builds so as not to slow down Release code).

In C / C++, assert macros usually print out the exact source code of the expression that failed the assertion check, which is often more than enough to understand the meaning of the failure.

In Java and Scala though, you have to provide your own message if you don’t want to be presented with an anonymous failure trace:

How often do you find yourself writing the following code?

Or, more recently (string interpolation FTW!):

Well, thanks to Scalaxy/Debug macros, you can now forget about this kind of grungy code:

You just need to add the following to your build.sbt file to get going:

Oh, and this works with assert, assume and require.

Enjoy! (please file any bug on Scalaxy/Debug’s GitHub and follow me on Twitter if you find this useful :-))

Posted in Uncategorized | Comments Off

Scalaxy/Loops: Optimized foreach loops for Scala 2.10.0 have landed (+ recap on ScalaCL)

In a hurry? Skip this lengthy post and go straight to Scalaxy/Loops!

Update: edited description of what “-inline” does in the last-but-one section.

Recap on an interesting performance issue

A couple of years back, I created a startup with a friend and got to write all our code in Scala, which included some Monte Carlo simulations for logistics planning optimization.

I was horrified to see that my seemingly barebones code didn’t run nearly as fast as I expected:

The reason why this code is much slower than its Java equivalent for loop is that it is desugared as…

… which creates a couple of objects at runtime and performs a truckload of method calls on them (each of these closures is an object, so the outer closure is created once and the inner closure is created once per iteration, and of course there’s a cost for calling each of them in each inner or outer loop iteration).

When I discovered this, I found myself starting to rewrite my code using while loops, like this:

But then my code became harder to read (I actually had nested loops on arrays, which looks even worse than ranges), and I wondered why I was doing this in Scala at the first place. Something had to be done.

Update: also see this great post on Loop Performance and Local Variables in Scala by Mark Lewis.

A first solution: compiler plugins (and ScalaCL was born!)

When I decided I couldn’t write while loops by hand, it’s quite naturally that I turned to Scala compiler plugins.

Steep learning curve, quite a few rough edges, but I soon released an optimizing compiler plugin that covered all of my needs: Range, Array, List with foreach, map, reduce, fold, scan… you name it!

Despite my repeated red warnings that this was experimental-ware, people started using ScalaCL for production purposes, I went to present ScalaCL at Scalathon 2011 and Devoxx France 2012, and the sky was blue (oh, and it was also capable of running Scala on GPUs in a very experimental way, incidentally, which may have confused a few…).

In the last months where I had time to work on that project, I started optimizing chains of collection calls, ending up with quite a complex piece of engineering that I eventually didn’t stabilize (version 0.3 was almost ready… and now it’s quite stale :-( ).

The catch with ScalaCL was:

  • Compiler plugins are a pain to write, and debug.
  • The internal APIs can be broken at every new release, making maintenance quite risky (and since I already had a few open-source projects to maintain, I had hardly enough hobby time left: JNAerator, BridJ and JavaCL).
  • Using the compiler plugin requires some special arguments for the compiler, and this scares some people off.

A new approach: macros

Now with Scala 2.10, we’ve got a shiny new API that exposes the internals of the compiler in a clean and (hopefully) future-proof way (although it’s still an experimental feature), which doesn’t require any setup of a compiler plugin.

Moreover, it brings an extremely powerful “reification” mechanism which allows for painless AST construction from macros.

Playing around with Scalaxy/Beans and Scalaxy/Fx last week just wasn’t enough: I had to restart my work on loops with macros:


This concludes a year of catching up with Scala 2.10 milestones, with various rewrites of ScalaCL and Scalaxy (+ an experiment on Compilets), and the scope is voluntarily smaller than before: Scalaxy/Loops optimizes simple loops (and does it well), period.

How to make your loops faster in 30 seconds

If you’ve started using Scala 2.10 and use Sbt, you’re in luck: just edit your build.sbt file as follows:

Now you just need to import scalaxy.loops._ and append optimized to all the ranges which foreach loops you want to optimize:

That’s it!

(so far it’s limited to Range.foreach, but Range.map and Array.map / .foreach might follow soon)

Cool, but (why) is it (still) faster?

Oh yeah, it’s faster!

I’m uncomfortable announcing speedups because it depends on your JVM, on your code, etc… But see for yourself (expect x3+ speedups for tight loops):

Scalaxy/Loops naive Benchmark

Now for the “why”, it’s a bit more complicated. My understanding is that the Scala team didn’t want to invest resources into such “specific” optimizations and instead chose to focus on more generalistic ones, like inlining.

Looking at code compiled with “-optimise -Yinline -Yclosure-elim” in 2.10, you can see that Range foreach method is indeed inlined… But not its closure (the call of which is what takes all the time :-( ).

Update: there’s some amazing work on a new Scalac optimizer going on, hope it magically solves all our issues in a future version!

Anyway, hope it’s useful to some people, and stay tuned for a stable release soon.

Keep in touch

Whether you file bugs in Scalaxy’s tracker, join the NativeLibs4Java mailing-list or ping me on Twitter (@ochafik), any feedback or help will be greatly appreciated!

Posted in Uncategorized | Comments Off

Scalaxy/Beans: type-safe macro-powered syntax candy for your Java beans in Scala.

Following up on my previous post that described a Type-safe dynamic beans factory with Scala 2.10 macros + Dynamic, I’ve modified the syntax of the hack…

… and made it available for use in Maven / Sbt projects.

Sources and tests are available on GitHub in Scalaxy/Beans.


Posted in Uncategorized | Comments Off

Type-safe dynamic beans factory with Scala 2.10 macros + Dynamic

With Scala 2.10.0 just out, we’ve now got a couple of shiny new toys:

  • Macros provide a clean (but experimental) way to plug into the Scala compiler, making AST rewrites very easy and mostly type-safe.
  • Dynamic is a type that lets you hijack method calls to predefined “fallback” methods (applyDynamic and al.).

The very interesting thing here is that despite its name, Dynamic only involves compile-time routing of unknown methods… and it is possible to implement applyDynamic using a macro!

This means using Dynamic you can create DSLs with code that is loosely typed (in Scala type system terms) and with macros we can still add your own custom compilation-time type-checks, and even rewrite the code so that it no longer refers to Dynamic at the first place!

Some practice: a type-safe dynamic beans factory

Java Beans are a bit tedious to create from Scala:

Well, with a Dynamic subclass that implements applyDynamicNamed using a macro, we can reach the following syntax:

And of course, this is all type-checked and rewritten to the exact same setter-intensive code as above, with the exact same runtime performance (nifty, isn’t it?).

Enjoy! (see newest sources and tests in Scalaxy’s repository)

Posted in Uncategorized | Comments Off

JavaCL 1.0.0-RC3 released: massive performance improvements, bugfixes, OSGi

JavaCL v1.0.0 RC3 is available!

Download / Install | Browse JavaDoc | Getting Started (Tutorial) | Discuss

JavaCL is a BSD-licensed library that lets you use OpenCL from Java, in order to run massively-parallel computations on your graphic card (and/or CPU).

Release Notes

Here are the main changes between 1.0.0-RC2 and 1.0.0-RC3 (see full change log) :

  • Fixed byte order hack for ATI platforms
  • Fixes / optimized event callbacks (but broke API: CLEvent.EventCallback now only takes the completion status as argument, not the event anymore)
  • Fixed library probe
  • Fixed handling of image2d_t and image3d_t in Maven plugin (contrib. from Remi Emonet, request #308 and issue #307)
  • Fixed OpenGL interop on Windows (issue #312)
  • Fixed error about mismatching byte order for byte buffers, and replaced mentions to getKernelsDefaultByteOrder() by getByteOrder() (issue #336)
  • Fixed AMD App 2.7 Linux library loading code for
  • Fixed AMD download link in demos.
  • Added CLEvent.FIRE_AND_FORGET to avoid returning events from all the methods that accept a vararg eventsToWaitFor.
  • Added naive OSGi support to the main JAR.
  • Added list of devices in program errors.
  • Added CLBuffer.allocateCompatibleMemory(CLDevice)
  • Added client properties to CLContext (lazy + concurrent)
  • Optimized low-level bindings on OpenCL 1.1+ platforms, with dynamic runtime switch (removed synchronized keyword from all native calls), and made OpenCL 1.0 synchronization a warning.
  • Enhanced CLDevice.toString (include platform name)
  • Deprecated CLKernel.enqueueNDRange with int[] parameters
  • Return CLUserEvent from CLContext.createUserEvent();

Getting started

You can read the Getting Started (Tutorial) page on the wiki to get started very quickly !

Please join the NativeLibs4Java Google Group to discuss JavaCL / ScalaCL, get the latest news and ask for support from the growing JavaCL community.

Posted in Uncategorized | Comments Off

JNAerator 0.11 released: ultra-fast raw bindings for BridJ, tons of critical fixes

JNAerator (licensed under LGPL 3.0) lets Java programmers access native libraries transparently, using a runtime such as BridJ (C / C++, BSD-license), JNA (C only, LGPL) or Rococoa (Objective-C).

As often, this new release contains tons of critical fixes, so all JNAerator users are strongly encouraged to migrate to this new version.

Here’s a summary of the changes between version 0.10 and 0.11 (see full change log here) :

  • Fixed infinite loops in simple typedefs (issue #288)
  • Fixed some -beautifyNames cases (issue #315)
  • Fixed parsing of some C++ templates (including template constructors)
  • Fixed “long long” regression
  • Fixed JNAeratorMojo.config documentation (issue #330)
  • Fixed long / long long / short pointer function return types
  • Fixed generation of BridJ C++ constructors
  • Fixed enum names that collide with Java identifiers (issue #334)
  • Added a type definition override switch, useful force mismatching 32/64bits types to some predefined types (for instance, -TmyVal=intptr_t)
  • Added raw bindings generation for BridJ
  • Added parsing of ‘using’ C++ statements
  • Added TypeRef.resolvedJavaIdentifier
  • Added parser support for `complex double` (cf. complex.h)
  • Added test for BridJ raw signatures
  • Moved to ECJ 3.7.2
  • Moved to JNA 3.4.0
  • Refactored type resolution and conversion
  • Rationalized CompilerUtils classpath + bootclasspath

Special thanks to the users and bug reporters that helped getting this version out !

You can contribute to the project by reporting bugs here and joining the NativeLibs4Java Community.

Wait no longer : try JNAerator through Java Web Start, or download it now !

Posted in Uncategorized | Comments Off