We made a minor change today to Xuggler. As far as we know, it doesn’t impact any existing users but we wanted to give a shout out to let people know: We’re no longer supporting using Xuggler via the C++ API, and we no longer allow commercial users to integrate with Xuggler via C++.
Why is this? Because we’ve found that (a) maintaining C++ backwards compatibility between releases is getting to be very restrictive, (b) 100% of our users and customers to-date (that we know of) have been using only Java to access Xuggler and (c) the current Windows binaries are built with G++ and we’ve had a lot of queries from people wanting to use MSVC++ instead (which we don’t use today).
By dropping official C++ API support the Xuggler project gets the following benefits:
- We can start to introduce exception throwing into the API now that we’re targeting primarily Java. C++ exception support across compilers is spotty (e.g. throwing exceptions across DLL boundaries on GCC under windows causes a crash) and was part of the reason we avoided them.
- We can make intelligent decisions about where to implement functionality; before today we tried really hard to add methods in both the Java API and the C++ API but frankly, some methods make more sense to add in Java code, whereas others make more sense to add in C++. A good example is the IStreamCoder#getExtraData() method we added today — it makes more sense to implement that method in Java, whereas the lower-level “copy into buffers” methods makes more sense in C++.
- We can break the binary C++ API and ABI across releases when it makes sense. Today we can’t change the order we declare methods in a C++ interface for fear that some other (non-Xuggle) person is using the API via C++. We can’t add data elements to a C++ class that’s part of the ABI. By removing this support, we can re-order methods, add data, and do whatever we need to more efficiently serve the Java API. Sine the Java JNI interface dynamically queries shared objects for functions, it doesn’t care about method order.
- We’re not giving false hopes to Windows developers that they can use Xuggler from C++ in their .NET applications, which helps lower some of our support costs.
Xuggler will continue to be implemented in C++, C, Assembly and Java — we’re just stopping claiming to support a C++ interface that no one is using, and is holding us back. AGPL users are free to build on the C++ API, but be aware we’re absolutely not going to support it or attempt to maintain compatibility on that interface between releases. We may at some point in the future introduce a C++ API that is supportable for us (and hopefully works with MSVC++), but that’s in the future.
Let me know if you have any questions, or you were using the C++ API and we weren’t aware.