any other Scala plugin devs?

Discussion in 'Spigot Plugin Development' started by bluekelp, Oct 15, 2018.

  1. I picked up Lyxnx's scala template a while ago ( -- github link no longer working) and haven't looked back. I begrudgingly revert to Java when I need to patch another plugin or support something I haven't rewritten yet.

    wondering if i'm the only one doing Scala + Minecraft and if not, what others are up to.

    my first enhancement was an immutable value class to replace Location so I didn't need to worry about mutability and forgetting to clone objects (which lead to all sorts of off-by-1 type logic errors and defects in my Java code - eventually making me litter .clone() calls everywhere).

    next I worked on getting rid of all my plugin's side-effects by introducing an Effect trait and having all my code return one of those. the GameMutator does all the nasty Unit function calling stuff -- which had the super nice result of me being able to unit-test the higher level parts of my plugins for once.

    then i dorked around and wanted a different paradigm to program plugins in so I borrowed Akka's FSM interface and fixed it because it was crap and had Unit/mutation all over the place. so now I have a pure/side-effect free FSM getup to track game/player states which react to various in-game or external events (like a scheduled heart-beat event for cool downs, etc.).
  2. MiniDigger


    do you have a project you can share?
    most ppl that switched away from java use kotlin now, scala is older, its prolly not hip enough for most ppl here :D
  3. I do whatever i feel like, Scala, Kotlin or Java... Also looked a Clojure once, i know @Proximyst was hyped about Clojure once. She might have reverted back to nonLisp though. Rust is prolly still her fav.
  4. I do all languages mentioned above, though Clojure will always keep its spot in my heart.
  5. Noob

    Sent from my iPhone using Tapatalk
    • Agree Agree x 1
  6. Most code I use Kotlin however for things that are Libraries I use Java(This is to prevent an over sized jar. ).

    val janTuck = spigotSite.getUser(" @JanTuck ")
    spigotSite.getThread(343184).reply("${janTuck.tag()} Hey:)")
    Kotlin is bae

    Back on topic. I have never tried Scala. I don't think I will.
  7. You really don't have to worry much about oversize jars anymore. :coffee:
    • Informative Informative x 1
  8. well... with the Scala runtime, cats, doobie, and a few others I ended up with a 31mb base once. lol. though I've seen my share of huge Java plugins too
  9. I haven't released anything. Not sure if I will, mostly I've been doing custom/pet projects for my own use. But I might update @Lyxnx's Scala plugin base and throw in a few goodies if I get around do it. IIRC that github repo is no longer available so it might be good karma to put something up for others to stumble into.
  10. MiniDigger


    oh just another note, scala heavily profits from oracles new JIT/JVM GraalVM. Twitter (the only company in the world that I know use scala, lol) use it in prod and saw double digits performance increases.
  11. Interesting! Twitter definitely is not the only one. We run everything on OpenJDK but I’ll keep this in mind. Fortunately we can generally scale horizontally but this is good to know for the times we cannot. I’ll have to dig in and learn more about why this is so much faster. Thanks for the info.
  12. MiniDigger


    It's just a new jit, written entirely in java, that is able to be optimized better because ppl actually understand the code now. With the current default jit in the jvm that's much harder, it's c++, it's ancient code, it's clustered with macros, there are prolly a few ppl in the world that can understand and patch the code.
    So it's a completely rewritten jit (remember, the jit is the most.important part of the jvm and the reason why java is so fast), with everything the world learned from option/c2, the old jit, most importantly to never use c++ to write a VM again. It's also already faster for most normal java applications.
    But while performance is nice with Graal, that's not even the coolest thing about it.
    Check out this
    • Like Like x 1
  13. I don't really do much with MC anymore mainly due to uni and work, however I do still use scala whenever I feel it's appropriate.
    It is good to see others using it though as I think it is quite an underrated and underused language (mainly with kotlin.)

    I have also fixed the github link and updated the code as I have learnt more things between then and now, plus I have added comments explaining everything because it would be nice for others to use it and I feel I am at a level that is experienced enough to teach others.
  14. No, you're not the only one doing Scala, I recently created a PluginLoader that can load plugin instances that use Scala's `object` syntax for singletons. It's also able to deal with multiple versions of Scala, and doesn't require ScalaPlugins to shade their own version of the Scala standard library.

    I haven't flushed out all the details yet (e.g. how do I handle craftbukkit's compatibility layer, how do I deal with JavaPlugins that use the Scala library), but it's already usable :)
    #15 Jannyboy11, Nov 9, 2018
    Last edited: Nov 9, 2018
  15. Nice! I’ll check it out. If one of my plugins bundles something like cats or doobie will those be available to other scala “plugins”?
    • Like Like x 1
  16. Scala is dead, long live to Kotlin! It's 100% interoperable with Java

    For developers dealing with Kotlin, I made a really powerful library named Kotlin4MC for BungeeCord, Spigot and Nukkit

    For example, listening to an event is like this
    Code (Java):
      it.player.msg("Hello world!")
    And like Jannyboy11's ScalaLoader, it bundles the Kotlin stdlib ;)
    • Optimistic Optimistic x 2
  17. Yep, if they use the same version of Scala. I'm using a classloader hierarchy:
    • The root of my hierarchy is a (java)PluginClassLoader, the one that bukkit's pluginloader creates for the ScalaLoader plugin itself.
    • Secondly there is a ScalaLibraryClassLoader for each version of Scala that have the 'root' classloader as parent. Classes from these loaders are NOT accessible to classes from other ScalaLibraryClassLoaders for obvious reasons.
    • Thirdly there are the ScalaPluginClassLoaders that use a ScalaLibraryClassLoader as parent. It cannot access the classes from other Scala versions (I should probably improve that, because minor version differences are still binary compatible). The classloader also tries to inject the classes into the JavaPluginLoader's classes cache so that JavaPlugins can access classes from ScalaPlugins. I'm using the word `tries` because it uses reflection which might fail on JRE9+ without the right commandline flags. Scala standard library classes are NOT injected into the JavaPluginLoader scope.
    • The ScalaPluginLoader makes classes from ScalaPlugin available to eachother by storing their classloaders in a Map, similar to the JavaPluginLoader.
    Scala is not dead at all, version 3 of the language is planned and will come with a formal type calculus, a bunch of new features and quality of life improvements. Read more about it here and here.

    My ScalaLoader doesn't bundle any scala library, it downloads only the necessary versions of the library at runtime ;). One of the reasons I created the plugin is because I didn't want those huge jars files such as your Kotlin4MC jar.
    #18 Jannyboy11, Nov 11, 2018
    Last edited: Nov 11, 2018
  18. Scala is far from dead, and your library looks horrible (yes, I'm a Kotlin dev myself, and you should not call yourself that with your Kotlin4MC.kt file).
    • Like Like x 1
    • Funny Funny x 1
  19. Why do you prefer downloading instead of bundling? From my point of view, it's still the same, right?

Share This Page