Spigot & BungeeCord 1.17 & 1.17.1

Discussion in 'News and Announcements' started by md_5, Jun 11, 2021.

  1. Yes, should be possible. Java is mostly backwards compatible.
  2. This depends on the exact version, Spigot has a version check built in that prevents you from running on a too high Java version. I believe 1.16 works on Java 16, not sure about anything before that.
    • Informative Informative x 2
  3. foncused

    Moderator Patron

    Tremendous work as always. Thank you for continuing to maintain this project after so many years and with such great agility to pump out regular updates when they are released.
    • Agree Agree x 1
  4. Maximvdw


    I would highly take that with a grain of salt for this java version
    • Agree Agree x 1
  5. Hmm, okay. What major changes should I be thinking about? Must say I'm not that familiar with all the functionality of Java 16 yet.
    • Agree Agree x 1
  6. How comes, have they dropped old calls? Whats more likely to break the server or the plugins?

  7. thanks a lot!
  8. md_5 I have problem while stop server upload_2021-6-11_19-36-48.png
  9. I almost can't believe it. That will be so awesome.
    • Funny Funny x 1
  10. I wonder if 1.17 has any sign of improved performance.
    • Like Like x 1
  11. Don't think so. But java 16 comes with a new faster garbage collector. You have to manually enable it tho and it can be unstable. I'll wait until more people have an experience with it.
  12. The Java version check was added in 1.13, so Spigot itself won't try to stop you from running it. In my recent tests (for something not directly related to the 1.12/Java version combination) I did not encounter any issues running 1.12.2 on Java 15 or Java 16 (can't remember exactly which one it was). Though some plugins might not like the change.
    The biggest issues with the new version of Java are that they removed some stuff (e.g. Nashorn) and that they have started to be more strict in what you are and are not allowed to do (you can't just do whatever you want with plain reflection anymore).
    • Like Like x 1
  13. If on linux, I recommend using SDKMAN for installing java. It has different java distributions (adoptopenjdk, openjdk, zulu, oracle, etc) and all their versions which can be installed by a single command.
  14. You can start buildtools with /path/to/java/version/bin/java -jar etc.. instead of just java -jar etc.. if you want to force it to be 11 or 8 for 1.12.2 or 1.16.5 (yes, java 16 and 1.16.5 works fine)
  15. Love the NMS changes. Thanks for your hard work as always.

    From what I can tell so far, NMS will actually become far easier to maintain for developers. Being able to directly use Mojang mappings and transform to Mojang obfuscation during compile is huge. It's going to take a bit of work to transfer my projects over to using it (I'm planning on just using obfuscated names for a day 1 release and taking a deep dive into it once the pressure is off), but I'm very excited about the prospect.

    It might even be (much more easily) possible to download mappings and generate revision-specific classes on the fly, which would be a huge game-changer. Not only would the generated classes be generated using Mojang's mappings, if any method used is changed you'd instantly be able to know and stop as opposed to the current approach most people (myself included) use: "Well, the current server uses the correct versioned package, but the backing Minecraft server has been updated since the one I compiled against... hope nothing changed!" Being able to support NMS in a way that Just Works(TM) would be absolutely fantastic.
    • Agree Agree x 1
  16. LoneDev


    What concerns me is the licensing stuff about porting my 1.16 NMS to Mojang mappings, because for what I understood it's against Mojang mappings TOS.
    So it would require devs who use NMS to code the NMS part of the plugin to be generated and "compiled" at runtime downloading Mojang mappings, right? Something similar to how BuildTools is compliant to Mojang rules.
    If this is true it would be a big problem because Spigot rules state that we cannot publish plugins that need internet connection to activate.

    Maybe I'm just overthinking
  17. My thought was to just include a compiled copy for the current "officially supported revision(s)" in addition to a generic compiled at runtime requiring an internet connection for any unsupported version.