On 12/10/2012, at 4:46 PM, Szczepan Faber wrote: > Hey, > > What's the main motivation of moving away from jna/jansi?
A good question. There're a few reasons: 1. In practice, it's easier to do portable native integrations using C + JNI than it is using JNA, in particular when structures and constants are involved. 2. In the case of jansi, we can get more accurate results using the native terminal APIs directly. For example, we can query the width of the terminal. And (in theory) have things work correctly under the cygwin terminal. 3. We can use native APIs in languages other than C. For example, languages like C# or Objective-C can be a better option for desktop integration. 4. We have a real project (with variants) to dog food the C++ plugins. And to drive a JNI plugin, too. 5. We have the capability to deliver native code on multiple platforms, which means we have a place to grow the native client. And longer term, a native tooling API. A native client would reuse the terminal stuff. The first 3 mean we can be a bit more ambitious in solving problems that would be difficult or not-so-robust in Java. For example, we can query file system meta-data to determine if a file repository is backed by a local or network file system, and cache things accordingly. Or we can use the platform's native credentials store to manage credentials. Or we can offer file change detection on JVMs < Java 7. Or nice integration with the desktop notification mechanism. Or listen to network interface changes to decide if we're offline or not. Or query the machine's memory usage to influence how we expire daemons. Or … There are a couple of downsides: 1. We need access to the hardware in order to implement and release the native integration. In practice, however, we need this access, regardless of how we implement the native integration, in order to test that it works (in particular when using JNA and structures are involved). 2. There's more code to write when calling a simple C function. However, most of the cost of a native integration is in testing and bug fixing, regardless of how it is implemented. > > Cheers! > > On Thu, Oct 11, 2012 at 8:19 AM, Adam Murdoch > <[email protected]> wrote: >> Hi, >> >> We've now started using our new native integration >> (https://github.com/adammurdoch/native-platform). Currently, we're using >> this integration to: >> >> 1. Detect the console. >> 2. Determine the width of the console. >> >> This is happening for Windows, Linux and OS X (for intel based machines >> only). If something goes wrong with either of the above, and for other >> platforms, we fall back to the existing jansi/jna based implementations. >> >> Nothing has changed with the actual rendering to the console. We're still >> using jansi for this. And nothing has changed with any of the other native >> stuff, such as UNIX file mode support and so on. >> >> This should allow us to shake out the native integration in a relatively >> safe way in Gradle 1.3. If it proves stable, we can migrate more stuff >> across in Gradle 1.4. >> >> So, please give a recent build a try and let me know if anything goes wrong >> with the console output. >> >> One question is how we should deal with platforms that are supported by the >> old integration but are not supported by the new integration. At the moment, >> these are: >> * FreeBSD on intel machines. >> * Solaris on intel machines. >> * Solaris on Sparc machines. >> * Linux on ia64 machines. >> >> The first 2 are not supported because I haven't gotten around to finishing >> the ports. The second 2 are not supported because we don't have access to >> any machines with this hardware. >> >> Some options for migration: >> 1. For a given integration feature, remove the jansi/jna/jna-posix backed >> implementation once the new implementation is available and stable. >> 2. Keep the jansi/jna/jna-posix backed implementations and remove them in >> Gradle 2.0. >> 3. Get hold of the above hardware (combined with #1 above). >> >> Each integration feature may have a different answer. For example, dropping >> support for console output is not necessarily a breaking change, so we might >> go with #1 for console support. Dropping support for file permissions, on >> the other hand, would be a breaking change, so #1 is no good in this case. >> >> The best overall option is #3, but to do this we would need to get some help >> with access to the hardware. I'm not sure of a good way to encourage folks >> to help here. I guess one option would be to drop console output on these >> platforms and mention in the release notes (and elsewhere) that we need the >> hardware. Or perhaps we just mention in the release notes that this support >> is deprecated and will be removed in Gradle 2.0 unless we can get help with >> the hardware. I don't think a deprecation nag message is appropriate in this >> case. >> >> >> -- >> Adam Murdoch >> Gradle Co-founder >> http://www.gradle.org >> VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting >> http://www.gradleware.com >> > > > > -- > Szczepan Faber > Principal engineer@gradleware > Lead@mockito > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > -- Adam Murdoch Gradle Co-founder http://www.gradle.org VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com
