Add server version util class #10253

masmc05 · 2024-02-16T12:36:32Z

Currently, it's impossible to get the information about the server from bootstrap, as Bukkit.getServer() is null.

The goal of this pr is to allow an easy access to information about the server, even from bootstrap.

Here's an example usage:

    // import static io.papermc.paper.util.ServerInfo.serverInfo;
    @Override
    public void bootstrap(@NotNull BootstrapContext context) {
        var log = context.getLogger();
        if (serverInfo().is("1.20.4")) {
            log.info("Server is running 1.20.4");
        } else {
            log.info("Server is not running 1.20.4");
        }
        if (serverInfo().is("1.20.3")) {
            log.info("Server is running 1.20.3");
        } else {
            log.info("Server is not running 1.20.3");
        }
        if (serverInfo().isAtLeast("1.20.3")) {
            log.info("Server is running 1.20.3 or newer");
        } else {
            log.info("Server is not running 1.20.3 or newer");
        }
        if (serverInfo().isAtLeast("1.20.6")) {
            log.info("Server is running 1.20.6 or newer");
        } else {
            log.info("Server is not running 1.20.6 or newer");
        }
        if (serverInfo().isAtLeast("1.20.7")) {
            log.info("Server is running 1.20.7 or newer");
        } else {
            log.info("Server is not running 1.20.7 or newer");
        }
        if (serverInfo().isAtLeast("1.20")) {
            log.info("Server is running 1.20 or newer");
        } else {
            log.info("Server is not running 1.20 or newer");
        }
        if (serverInfo().isAtLeast("1.21")) {
            log.info("Server is running 1.21 or newer");
        } else {
            log.info("Server is not running 1.21 or newer");
        }
        if (serverInfo().isImplementing(Key.key("papermc", "folia"))) {
            log.info("Server implements folia");
        } else {
            log.info("Server does not implement folia");
        }
        //Logically, this should always return true
        if (serverInfo().isImplementing(Key.key("papermc", "paper"))) {
            log.info("Server implements paper");
        } else {
            log.info("Server does not implement paper");
        }
        log.info("Server version: {}", serverInfo().version());
        log.info("Server version name: {}", serverInfo().versionName());
        log.info("Bukkit version: {}", serverInfo().apiVersion());
        log.info("Server brand: {}", serverInfo().serverBrand());
    }

which results in those outputs (Bukkit version remained the same since it's unknown how it will be in reality for a snapshot etc, just changed the version.json file to ones provided in other versions)
For 1.20.6:

[22:46:04 INFO]: [Paper-Test-Plugin] Server is not running 1.20.4
[22:46:04 INFO]: [Paper-Test-Plugin] Server is not running 1.20.3
[22:46:04 INFO]: [Paper-Test-Plugin] Server is running 1.20.3 or newer
[22:46:04 INFO]: [Paper-Test-Plugin] Server is running 1.20.6 or newer
[22:46:04 INFO]: [Paper-Test-Plugin] Server is not running 1.20.7 or newer
[22:46:04 INFO]: [Paper-Test-Plugin] Server is running 1.20 or newer
[22:46:04 INFO]: [Paper-Test-Plugin] Server is not running 1.21 or newer
[22:46:04 INFO]: [Paper-Test-Plugin] Server does not implement folia
[22:46:04 INFO]: [Paper-Test-Plugin] Server implements paper
[22:46:04 INFO]: [Paper-Test-Plugin] Server version: 1.20.6
[22:46:04 INFO]: [Paper-Test-Plugin] Server version name: 1.20.6
[22:46:04 INFO]: [Paper-Test-Plugin] Bukkit version: 1.20.6-R0.1-SNAPSHOT
[22:46:04 INFO]: [Paper-Test-Plugin] Server brand: Paper

lynxplay · 2024-02-17T18:45:39Z

I believe the concept here is great, I am currently unsure if the impl and api methods are the best tho.

A) int varargs seems weird. This would lock the API to only support major versions, which I am unsure is something we want to commit to.
B) I like implement (tho it should be implements). This seems especially useful for forks as you pointed out, e.g. purpur or folia. Is a single string there enough or should we force some form of namespace? I presume the chances of a second fork named purpur that does not actually supply purpur apiare slim to none, but yea, food for thought.

TheMeinerLP · 2024-02-17T18:53:17Z

Wouldn't it make more sense to transfer this Check Logic into the PaperLib and rather return Try Version String and Protocol Version into the bootstrap context ?

So this is just a suggestion

Sytm · 2024-02-17T19:05:23Z

I think this stuff fits best into the server, because only the server can reliably tell what it implements. The checking for classes (what PaperLib does) might not properly reflect everything depending on what is checked

TheMeinerLP · 2024-02-17T19:08:11Z

I think this stuff fits best into the server, because only the server can reliably tell what it implements. The checking for classes (what PaperLib does) might not properly reflect everything depending on what is checked

Well, if PaperLib can test on the basis of given things. Bootstrap context or other things. You don't have to do anything with Reflections if the correct values are given. I see such a version check more as an ultitiy than that it should be part of a server software. But that's more my perspective.
The other side of it would be that developers would have it easier.
But is it worth the maintainability?

masmc05 · 2024-02-17T22:05:02Z

I believe the concept here is great, I am currently unsure if the impl and api methods are the best tho.

A) int varargs seems weird. This would lock the API to only support major versions, which I am unsure is something we want to commit to. B) I like implement (tho it should be implements). This seems especially useful for forks as you pointed out, e.g. purpur or folia. Is a single string there enough or should we force some form of namespace? I presume the chances of a second fork named purpur that does not actually supply purpur apiare slim to none, but yea, food for thought.

A) I will think how I could change that

B) Sadly, "implements" is a reserved word by java, that's why it's "implement". And what are the guarantees that that other fork won't use the same namespace? If someone named their fork exactly the same as other fork in my opinion it's their fight, I made this method mostly for popular forks, like folia, since if a plugin will make a special support for a fork, it's really not likely it will make it for a small unknown fork.

lynxplay · 2024-02-17T22:09:24Z

kek, yea you are right. flame my tired brain. implement is still not nice. offers ? providesAPI.

masmc05 · 2024-02-17T22:22:36Z

But is it worth the maintainability?

You can look at the implementation, it's based on 3 information from the nms

The version. From 1.13, nms has a class named SharedConstants, which always had the version, but they may often change how to get it from that class, if they change it a bit, it won't be hard to find the new method in the SharedConstants to get the version, but it breaks compatibility for the plugins using reflection
The api version. Well, this depends on Versioning class, which didn't change for the last 12 years, i don't think this will bring any trouble
The server name. I don't think someone ever will want to touch this... And it's based on an own class, so it's independent from future changes, also here goes the check for implemented apis
The UnsafeValues. It's the same unsafe as in Bukkit#getUnsafe, if people depend on it, they're on their own, so this doesn't have any maintainability burden at all

Also this pr doesn't modify any classes, just adds some new, so it's reaaaalllyyy cheap to maintain.

Wouldn't it make more sense to transfer this Check Logic into the PaperLib

Why should I use paper lib if I only support paper, in a paper plugin, just to check the version.....

masmc05 · 2024-02-17T22:23:01Z

kek, yea you are right. flame my tired brain. implement is still not nice. offers ? providesAPI.

Maybe then hasAPI?

Leguan16 · 2024-02-17T22:36:40Z

What about isImplementingAPI?

masmc05 · 2024-02-17T22:40:45Z

What about isImplementingAPI?

I think if (PaperServerInfo.isImplementing("Folia")) sounds as the best solution

The "api" in the method name makes it a bit too verbose

Leguan16 · 2024-02-17T23:30:26Z

But I also think that some sort of name spacing wouldn't be bad. It looks weird to provide a String imo.

vadcx · 2024-02-18T00:55:40Z

I'm pleased to see the discussion taking place here, let me respond to respond points first:

The server name. I don't think someone ever will want to touch this...

But isn't Paper as much Spigot (the server, not the plugin), as it is CraftBukkit?

Sadly, "implements" is a reserved word

The point here is feature-based interaction and enablement. I strongly believe this should be called .supports() or similar. Supports Folia? Yes. Suports X-Y patch from 1 year ago? No. Supports a sub-feature of a patch from 9 months ago? Yes.

should we force some form of namespace?

If the API operates on strings, idk how do you want to enforce it? Change the API to explicitly require a parent namespace key + child key? This is little different from a convention calling features like "paper.versioningapi". This then will be similar to how browsers implement experimental/proprietary CSS features by adding a -webkit or -moz prefix.

Versioning of the Features? If this idea evolves to a feature-support API, at some point it'll be useful and necessary to retrieve a feature's individual version number. The game/server revision could be used for it, but it's more work and less reliable than knowing a certain patches' exact version.

"Just add a more specific key to a patch" is not the complete answer, because there can be a patch gap between a behavioral change/feature's implementation and the understanding that it warrants a new, more specific feature key.

Although I'm surprised by vararg version ints too, my question is different. How to work with and represent weekly snapshots? And the absolute edge case, special editions like April 1st (ok this is over the top).

For "isVersion" I would add CAPS docs to instead use greater/lower than for versioning (especially if this PR moves toward capability-based API queries). Because isVersion should be understood as hardcoding an exact version in the majority of cases.

I find this is a better (and more gentle) solution for a seamless multi-version and multi-vendor support than reflection/exceptions. It'd be better placed in upstream (Spigot).

patches/server/1046-Add-paper-version-util-class.patch

masmc05 · 2024-02-18T08:55:02Z

Versioning of the Features? If this idea evolves to a feature-support API, at some point it'll be useful and necessary to retrieve a feature's individual version number. The game/server revision could be used for it, but it's more work and less reliable than knowing a certain patches' exact version.

I think this will bring too much trouble to maintain, all changes to features are made to have backwards compatibility, so you may just need to check for the version + fork api presence to see if the new feature capability is here

But isn't Paper as much Spigot (the server, not the plugin), as it is CraftBukkit?

As I see it, very soon the hard fork will happen, then it will be very hard to say that the server is implementing the spigot/bukkit api, adding something with the scope of removing it very soon is not a bright idea in my opinion

The point here is feature-based interaction and enablement.

The point is the implemented fork api, as novice developers often may forget to store the value if the server is folia, meaning they will have often Class#forName calls, which are expensive, this new method should be safe to recommend in docs and other places for new developers. Also this is a way easier method than to find the class and copy it for class check.

Although I'm surprised by vararg version ints too, my question is different. How to work with and represent weekly snapshots? And the absolute edge case, special editions like April 1st (ok this is over the top).

I thought about changing PaperServerInfo#is to a string which just checks for equals with current version and PaperServerInfo#isAtLeast will just mean if the current version appeared after the specified release version or if it's the current release version

I find this is a better (and more gentle) solution for a seamless multi-version and multi-vendor support than reflection/exceptions. It'd be better placed in upstream (Spigot).

Personally, I don't want to care about the spigot api, if people want to still support spigot, then they may continue to just deal with the missing api like this, I didn't support spigot in my plugins for a long time and recommend others to do the same (even though I understand that private plugins are a lot easier to make without spigot support than public/paid plugins)

masmc05 · 2024-02-19T20:39:57Z

Made a few changes which we discussed here, like using a key to check for implemented api and support for non-release versions.

The support for snapshots/pre-releases could be made better but I don't think that it's an environment for which we may want to spend too much effort to give the best support possible. But at least this pr already defines a possible future behaviour that developers may expect, and which can be further discussed here.

The usage and the output were updated to reflect the changes.

DerEchtePilz · 2024-02-19T21:37:08Z

I really like this concept but I am unsure if the class should be named PaperServerInfo. Why not name it ServerInfo?

masmc05 · 2024-02-19T21:44:08Z

I really like this concept but I am unsure if the class should be named PaperServerInfo. Why not name it ServerInfo?

Idk, PaperServerInfo sounds better for me, but if someone else agrees then i can change that to ServerInfo

DerEchtePilz · 2024-02-19T21:48:57Z

Idk, PaperServerInfo sounds better for me, but if someone else agrees then i can change that to ServerInfo

Well, I think for Paper it's fine either way but I was much more thinking of forks for example. Sure, they can patch that name again but naming it ServerInfo is much more generic than PaperServerInfo.
I don't know, these are just my thoughts about this..

Leguan16 · 2024-02-23T19:45:19Z

I agree with DerEchtePilz on this one. PaperServerInfo seems more like a implementation name than an API name. The whole bukkit API is meant to be generic so I would not stop here and start naming things after Paper. Though maybe a different name then ServerInfo can be found. IMO it doesn't really fit. Since it mostly is about the version maybe call it VersionInfo or generally just Version.

masmc05 · 2024-02-23T21:41:23Z

I agree with DerEchtePilz on this one. PaperServerInfo seems more like a implementation name than an API name. The whole bukkit API is meant to be generic so I would not stop here and start naming things after Paper. Though maybe a different name then ServerInfo can be found. IMO it doesn't really fit. Since it mostly is about the version maybe call it VersionInfo or generally just Version.

"VersionInfo" or "Version" already does not go well with isImlementing, also limits future possibilities to add utility methods

Who knows what other information about the server people may want to get in the bootstrap, naming it "ServerInfo" will give green light to a lot of read only operations that may be invoked before CraftServer exists, I just added mostly only version methods because that's the most used thing right know but which is inaccessible in bootstrap, and don't think other methods may fit well in this pr

~~I'll rename the class to "ServerInfo" these days when I'll have a bit of free time~~ Renamed

patches/server/1048-Add-paper-version-util-class.patch

patches/api/0464-Add-paper-version-util-class.patch

masmc05 · 2024-04-28T15:17:37Z

Rebased on 1.20.5

Leguan16 · 2024-04-30T22:10:19Z

Wouldn't this be a great addition to the removal of relocation to provide a straightforward way of getting the version? I mean it would only work from 1.20.(5/6)+ but I guess it's good to include both in the same version so there is a nice and modern alternative.

lynxplay

So after a bit of discussion on this, I think we'd be (for now) best of to only
pull changes regarding full release versions.

Snapshot handling is complex, specifically with isAtLeast.
The commits in this PR will keep the logic around, so when we do get to releasing paper for snapshots they can serve as starting point.

Beyond that, see below for changes for request.
Again, thank you for the pr 🥳

patches/api/0477-Add-paper-version-util-class.patch

patches/server/1046-Add-paper-version-util-class.patch

masmc05 · 2024-05-12T20:01:00Z

Applied all requested changes

masmc05 · 2024-05-12T20:28:27Z

Fixed the javadoc which failed the workflow

patches/api/0479-Add-paper-version-util-class.patch

patches/server/1049-Add-paper-version-util-class.patch

masmc05 · 2024-05-13T07:24:36Z

Applied all requested changes

…r class

kashike · 2024-05-15T06:52:45Z

Hey @masmc05! Thanks for your work on this pull request! ❤️ We've merged (most) of your work into #10729 where we've done some other changes related to versioning, and we'll be continuing this pull request over there. Feel free to comment over there.

Note: there are some minor differences, and there are one or two methods missing in #10729 currently.

masmc05 · 2024-05-15T07:41:43Z

Hey @masmc05! Thanks for your work on this pull request! ❤️ We've merged (most) of your work into #10729 where we've done some other changes related to versioning, and we'll be continuing this pull request over there. Feel free to comment over there.

Note: there are some minor differences, and there are one or two methods missing in #10729 currently.

Yeah, I noticed, I'm glad that my work was able to help creating an even bigger addition to paper.
Will soon then try to get my second pr to be my first merged pr, as Amaranth suggested on Discord, with a change smaller than this (not something like world generator api v2)

Add paper version util class

e1ce250

masmc05 requested a review from a team as a code owner February 16, 2024 12:36

masmc05 marked this pull request as draft February 17, 2024 22:25

vadcx reviewed Feb 18, 2024

View reviewed changes

patches/server/1046-Add-paper-version-util-class.patch Outdated Show resolved Hide resolved

vadcx reviewed Feb 18, 2024

View reviewed changes

patches/server/1046-Add-paper-version-util-class.patch Outdated Show resolved Hide resolved

Multiple changes

40d804f

masmc05 marked this pull request as ready for review February 19, 2024 20:31

masmc05 and others added 2 commits March 2, 2024 18:54

Merge branch 'PaperMC:master' into paper-info

f6ed17a

Merge upstream and rename class to ServerInfo

e641795

yannicklamprecht suggested changes Mar 3, 2024

View reviewed changes

patches/server/1048-Add-paper-version-util-class.patch Outdated Show resolved Hide resolved

Leguan16 reviewed Mar 3, 2024

View reviewed changes

patches/api/0464-Add-paper-version-util-class.patch Outdated Show resolved Hide resolved

masmc05 and others added 3 commits April 28, 2024 17:31

Merge branch 'PaperMC:master' into paper-info

d0d5faf

Rebase on 1.20.5

4fc6c32

On snapshots, fetch the version list in async

7b98d0d

masmc05 and others added 4 commits May 1, 2024 22:14

Apply new rules against var and change #isStable to #isRelease

a505bb3

Merge branch 'PaperMC:master' into paper-info

92b405d

Merge remote-tracking branch 'origin/paper-info' into paper-info

b12426d

Rebase

2d0b20b

lynxplay requested changes May 11, 2024

View reviewed changes

kashike requested changes May 12, 2024

View reviewed changes

masmc05 and others added 2 commits May 12, 2024 21:13

Merge branch 'PaperMC:master' into paper-info

b458e9d

Apply requested changes

9438de5

Forgot to commit the additional </ul>

2b74eae

Machine-Maker requested changes May 13, 2024

View reviewed changes

patches/api/0479-Add-paper-version-util-class.patch Show resolved Hide resolved

patches/api/0479-Add-paper-version-util-class.patch Outdated Show resolved Hide resolved

patches/server/1049-Add-paper-version-util-class.patch Outdated Show resolved Hide resolved

Apply requested changes p2

fd39cad

Inspiration from PaperMC#10710 on how to better deal with local holde…

f5401ec

…r class

kashike closed this May 15, 2024

masmc05 deleted the paper-info branch May 15, 2024 07:41

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add server version util class #10253

Add server version util class #10253

masmc05 commented Feb 16, 2024 •

edited

lynxplay commented Feb 17, 2024

TheMeinerLP commented Feb 17, 2024

Sytm commented Feb 17, 2024

TheMeinerLP commented Feb 17, 2024

masmc05 commented Feb 17, 2024

lynxplay commented Feb 17, 2024

masmc05 commented Feb 17, 2024

masmc05 commented Feb 17, 2024

Leguan16 commented Feb 17, 2024

masmc05 commented Feb 17, 2024 •

edited

Leguan16 commented Feb 17, 2024

vadcx commented Feb 18, 2024 •

edited

masmc05 commented Feb 18, 2024

masmc05 commented Feb 19, 2024 •

edited

DerEchtePilz commented Feb 19, 2024

masmc05 commented Feb 19, 2024

DerEchtePilz commented Feb 19, 2024

Leguan16 commented Feb 23, 2024

masmc05 commented Feb 23, 2024 •

edited

masmc05 commented Apr 28, 2024

Leguan16 commented Apr 30, 2024

lynxplay left a comment

masmc05 commented May 12, 2024

masmc05 commented May 12, 2024

masmc05 commented May 13, 2024

kashike commented May 15, 2024

masmc05 commented May 15, 2024

Add server version util class #10253

Add server version util class #10253

Conversation

masmc05 commented Feb 16, 2024 • edited

lynxplay commented Feb 17, 2024

TheMeinerLP commented Feb 17, 2024

Sytm commented Feb 17, 2024

TheMeinerLP commented Feb 17, 2024

masmc05 commented Feb 17, 2024

lynxplay commented Feb 17, 2024

masmc05 commented Feb 17, 2024

masmc05 commented Feb 17, 2024

Leguan16 commented Feb 17, 2024

masmc05 commented Feb 17, 2024 • edited

Leguan16 commented Feb 17, 2024

vadcx commented Feb 18, 2024 • edited

masmc05 commented Feb 18, 2024

masmc05 commented Feb 19, 2024 • edited

DerEchtePilz commented Feb 19, 2024

masmc05 commented Feb 19, 2024

DerEchtePilz commented Feb 19, 2024

Leguan16 commented Feb 23, 2024

masmc05 commented Feb 23, 2024 • edited

masmc05 commented Apr 28, 2024

Leguan16 commented Apr 30, 2024

lynxplay left a comment

Choose a reason for hiding this comment

masmc05 commented May 12, 2024

masmc05 commented May 12, 2024

masmc05 commented May 13, 2024

kashike commented May 15, 2024

masmc05 commented May 15, 2024

masmc05 commented Feb 16, 2024 •

edited

masmc05 commented Feb 17, 2024 •

edited

vadcx commented Feb 18, 2024 •

edited

masmc05 commented Feb 19, 2024 •

edited

masmc05 commented Feb 23, 2024 •

edited