Are we allowed to upload native libraries to BukkitDev? [Answer: No]

Discussion in 'BukkitDev Information and Feedback' started by Cirno, Apr 6, 2015.

Thread Status:
Not open for further replies.
  1. Offline

    Cirno

    I currently have code that relies on my own native library to hook into avcodec and avformat; all of which are written in C++ and are compiled with g++. Are we allowed to upload plugins that depend on a native library, given if I distribute my native library and then require the user to download avcodec and avformat if they wish to utilize the feature that requires them?
     
  2. Why would you need a native library?
     
    timtower likes this.
  3. @Cirno Well the only thing to judge by is the official guidelines. Curse don't follow these guidelines, so give it a shot! If they reject it, oh well.
     
  4. Offline

    Cirno

    I'm currently trying to "revamp" videos within Minecraft via maps and the old traditional way of doing it was to download the video (if remote), convert it to a .gif via a FFmpeg binary, and then use a GIF decoder to load each and every individual frame. If you can't already tell, this was a highly convoluted and inefficient way of getting frames from a video, however, it was the only "pure Java" (minor exception of using Runtime.exec() to run FFmpeg) way that yielded the "most" performance at the cost of more "preparation" time. I've experimented with JCodec and the performance on it was horrendous, as for JME (I think that's what it was called?) is outdated beyond belief. This is when I started to look for alternatives, and that's when I started exploring what FFmpeg uses. I'm only using avcodec and avformat as those are the two relevant libraries needed, however, they're both native libraries. I was able to 1) improve performance substantially (one heavy factor that might have curved it: 1.8 map packet changes and how 1.8 updates maps) and 2) remotely stream videos (part of avformat I believe) without having to download it in the first place. However, all of this comes at a extremely price. Should the native library error, the JVM does NOT handle the error and brings down the entire JVM (can be defeated if the native library attempts to handle exceptions). Along with this, it defeats the Java philosophy of "write once, run everywhere" (though this cavart can easily be solved with cross-compilation). Another "concerning" factor is the exploitation of these libraries. JNI is a beautiful thing, don't get me wrong, but it's like using sun.misc.Unsafe because it has _unrestricted access to any libraries that are installed on the system_ (including those that are included, for instance, in Windows) which can enable anyone with half a brain and the will to learn C/C++ to write malware under the guise of a Bukkit plugin.

    tl;dr Native libraries yield faster performance at the possible (notice "possible") risk of degrading security and the possibility (notice "possibility") of crashing the entire JVM.

    Should've probably never mentioned the malware aspect of all this, as it defeats my entire request, but it's something to heavily consider.
     
  5. @Cirno I stand by my statement that the fastest way to tell would be to just do it and see what happens. They don't seem to answer questions anymore, so there's that.
     
  6. Offline

    Cirno

    "This project contains a native/encrypted library, which we do not allow on our sites."
    That's a wrap.
     
Thread Status:
Not open for further replies.

Share This Page