BossBar Changes

[TurboJax]

I've been looking a lot at the BossBar api and wanted to propose a few changes.
I'm not one to figure out when things should be deprecated/removed, but I can throw out deprecation in v5, removal in v6 as a plan.

1. Converting BossBar to a class and removing BossBarImpl.
   • BossBar is currently a sealed interface with BossBarImpl being its only permitted implementation.
   • I don't think that there are any plans to make another implementation of BossBar (correct me if I'm wrong).
   • This won't break any of the main implementations of adventure. The Paper, Velocity, Sponge, Fabric, and NeoForge implementations not only still use the adventure 4 api, but they all use BossBar instead of BossBarImpl.
   • It can also reduce confusion between BossBarImpl and BossBarImplementation, as they have similar names.
2. Remove HackyBossBarPlatformBridge.
   • Only the Sponge API uses this class, and it's used to make BossBarImpl inherit their BossBarBridge class.
   • The mixin can easily target BossBarImpl (or BossBar if it becomes a class) instead of HackyBossBarPlatformBridge. (Correct me if I'm wrong)
   • This may cause api issues, so the class should probably be deprecated instead of outright removed.
3. Make BossBar#viewers and BossBarViewer#activeBossBars return Sets instead of Iterables.
   • This may just be the beginner in me, but I feel like Sets are easier to handle than Iterables.
   • In this case BossBar#viewers would go from returning Iterable<? extends BossBarViewer> to Set<BossBarViewer>, and BossBarViewer#activeBossBars would go from Iterable<? extends BossBar> to Set<BossBar>
   • This is just me bringing up something I mentioned in feature(api): Remove BossBarViewer #1370 but adapted for if that pr doesn't go through.

Thoughts?

[Strokkur424]

1. Basically all adventure API types are interfaces, so I don't think there exists any reason for why BossBar specifically should not be an interface either. Furthermore, changing it at this point would result in binary incompatibility. The reason being that when you call a method on an interface, the JVM bytecode does an invokeinterface call. If it were a class, the JVM bytecode would actually be an invokevirtual call, which is different. Thus plugins using the old API would no longer work.

2. This one is weird for sure. I have nothing to do with Sponge, so I will not say anything here.

3. I don't necessarily have a strong opinion on whether Iterable or Set is better. I personally would probably also choose Set, as I generally expect the values to be unique, and it provides some better utilities regarding "hey is this Audience inside the viewers?". However the wildcard generic should be kept. The difference between BossBarViewer and ? extends BossBarViewer is that the second (and current) one is much better for implementing the methods returning those. If you return, let's say Set<BossBarViewer>, then you have to provide a set typed with BossBarViewer, meaning if you have an Audience, eventhough it implements BossBarViewer, you might actually still manually cast it to BossBarViewer. ? extends BossBarViewer just tells the Java compiler "Yeah so any set with values that extend/implement BossBarViewer are fine, you can mix/match types!". I cannot tell you the specifics as to why this distinction was made in the Java language specs, but it exists.

tl;dr: neither 1. or 3. are fully feasible due to the way Java works.