Minecraft Version & Java Version Requirements about treasury

[Geolykt]

I understand the emotion of being ahead of the curve, but let's be real - what does 1.17 offer that 1.8 cannot?
Similarly is java 17, is there any real need to have it? New java API may look fancy, but strictly speaking is not really needed at all. #37 is an example of reimplementing newer Java API to fit our need more closely. In most cases there isn't an all too significant drawback to that. The only instances where we cannot work around is if we were to make use of JPMS (bukkit and JPMS do not pair themselves well though, so it's unlikely to happen).

[Jikoo]

Consumer is actually Java 8, it's not a selling point either way. The only reason Bukkit contains a Consumer (which is basically identical to Java's inbuilt functional interface) is because when it was added Bukkit was targeting Java 6.

There are definitely cases where it could be cleaner to use new features (i.e. https://github.com/Craftstuebchen/Tresor) but many require Java 17, which will not be widely adopted for some time. Per bstats, Java 17 comprises 2% of servers. Java 8 is down 0.6% since I checked last week to 27.6%

[Geolykt]

Treasury itself should be pretty platform agnostic, so limiting the minecraft version does not make any sense. However this is not the case with Java as it provides enhancements that could vastly improve certain aspects with new features such as Records.

[Jikoo]

Re: MC version - I'm also of the mind that it doesn't matter. Treasury is ideally going to be a platform-agnostic API. I think Treasury should include api-version: "1.12" in its plugin.yml to prevent unnecessary legacy material support loading, but it really doesn't need to care what MC version is present otherwise (assuming the messaging system supports hex and regular colors, I can see that being a complaint).

Are you really challenging me!?

You do realize this is a discussion thread, right? The whole point is to present arguments. Yours aren't particularly compelling.

• Toxicity of communities: Treasury isn't an implementation, as long as its few commands function there should be no reason to ever be in contact with most server owners.
• Performance of the JVM: If a server is suffering poor performance, it's the owner's decision to update. Trying to force server owners to do something (even if it's for their own good) will only limit Treasury's adoption.
• Records: Records are great, but you didn't point out anywhere in the API where they'd be useful. I can think of a few places, but regular data holders also would work fine. Honestly, if your IDE isn't doing 99% of the QoL records add for you, you really need to learn to work smarter or get a better IDE. Generating getters takes maybe 4 clicks total, same with toString and hashCode. I get that it's extra work, but it's not a backbreaking amount of work considering the market share at stake.
• Other features: These are all nice things, but how are they relevant to Treasury? How will they improve the API Treasury offers? Implementations are free to use a higher language level. Treasury is just the API.

I think the crux of the issue is that this is a Vault competitor. It will be more convenient to use, is that worth the price of accessibility? Is Treasury interested in sacrificing 25% or more of its potential market share for developer quality of life?

Personally, given that it is possible to compile and include an adapter module for a higher language level that wraps the interfaces with more modern features, I would say no. I don't particularly like it, I really would prefer to work with at least Java 16, but realistically I think the market share increase is too large to ignore.

[Geolykt]

I don't see any use in requiring java 11, it does not have any interesting features over java 8 apart from the java platform module system (JPMS). Java 16 or Java 17 on the other hand does look interesting, but I'm not all too convinced that it makes any sense to bump to it prematurely. If the impl chooses to use a higher java version then it is free to do so, but it is not possible to choose a lower java version without serious efforts beforehand.

[MrIvanPlays]

I agree that we need to put this on hold and wait for 1.18 to see what mojang will do.

[MrNemo64]

1.18 is going to use java 17.

I'm so glad that Mojang is finally forcing people to update their Java. I hope they continue this trend with each new Java release, or at least, every new LTS release.

Hopefully they follow the bi yearly cycle. No need to stay on LTS.

I think updating is the right move. We can finally start to leave java 1.8 behind

[lokka30]

I believe we should stay with the following minimum requirements:

• Java 8
• MC 1.7

As much as I would like to make Treasury use Java 17, we need to consider that:

• All plugins using Treasury will need to also update to Java 17
• Server owners that run 1.7/1.8/1.12 will not be able to utilize Treasury. There might be a launch flag fix or something but this might not be viable for these server owners.

The Minecraft version here doesn't really matter because Treasury does not utilize any version-specific features other than what is present in the Bukkit API at the time. That's why we can comfortably support back to 1.7 without putting a burden on us.

I don't know what Java 17 will bring us other than record classes. We can live without it.

Down the line we can absolutely change the bar of which servers can run Treasury or not if we need to. But we should only be modifying this if it's necessary, not for minor programmer luxuries.

[MrIvanPlays]

Similarly is java 17, is there any real need to have it?

Are you really challenging me!? The difference in terms of performance and code features since java 8 is from the ground to the moon and back. The most important thing being that we have better garbage collecting on newer versions and many more ( lost track of them ).

As for code features, we have the best of them: records
Instead of doing this:

public class A {
  private final String foo;
  private final int bar;
  
  public A(String foo, int bar) {
    this.foo = foo;
    this.bar = bar;
  }
  
  public String foo() {
    return foo;
  }
  
  public int bar() {
    return bar;
  }
  
  // toString and hashCode, cba to write them too
}

you just do this 1 line bby:

public record A(String foo, int bar) {}

Then we have better switch expressions (cba to give an example), sealed types, local enums, local interfaces, etc., etc.

As for version difference - yeah treasury can run on 1.8, but my point here is not "what does 1.17 offer that 1.8 cannot", my point is that if you continue to support ancient versions such as 1.8, the 1.8 servers won't shrink, by "won't shrink" I mean they won't update, because it is comfortable for server owners to force developers to support 1.8 rather than developers force people to update. "but pvp 1.8 mucc beta" there are plugins which emulate this behavior "but they dont at 100 pursent" shut the fuck up and update. UPDATE

[MrNemo64]

shut the fuck

Lets try to avoid these words, no need to use them

Similarly is java 17, is there any real need to have it?

Are you really challenging me!? The difference in terms of performance and code features since java 8 is from the ground to the moon and back. The most important thing being that we have better garbage collecting on newer versions and many more ( lost track of them ).

As for code features, we have the best of them: records Instead of doing this:

public class A {
  private final String foo;
  private final int bar;
  
  public A(String foo, int bar) {
    this.foo = foo;
    this.bar = bar;
  }
  
  public String foo() {
    return foo;
  }
  
  public int bar() {
    return bar;
  }
  
  // toString and hashCode, cba to write them too
}

you just do this 1 line bby:

public record A(String foo, int bar) {}

Then we have better switch expressions (cba to give an example), sealed types, local enums, local interfaces, etc., etc.

As for version difference - yeah treasury can run on 1.8, but my point here is not "what does 1.17 offer that 1.8 cannot", my point is that if you continue to support ancient versions such as 1.8, the 1.8 servers won't shrink, by "won't shrink" I mean they won't update, because it is comfortable for server owners to force developers to support 1.8 rather than developers force people to update. "but pvp 1.8 mucc beta" there are plugins which emulate this behavior "but they dont at 100 pursent" shut the fuck up and update. UPDATE

While I understand your point I'm more of the mind set of "You shouldn't have to buy a new printer just because you bought a new pc". New tecnology should support old one. Although java has some new features that I would love to use, is it really necessary? We are creating a competitor for Vault, 4th most downloaded plugin on the spigot page, we need to provide at least as much as vault, that not only means features and updates, also versions.
How much time does it take you to create a new class instead of a record? Creating a class is not that hard, your IDE will do the heavy lifting (getters, setters, constructors, etc).
And who knows? Maybe the server uses a plugin that was abandoned and remains unupdated since 1.8.
Why fix it if it is not broken? yeah, new java versions perform better but do the server owners have enough performance issues to go throught the pain of updating? Running a server is about attracting players and 1.8 attracts PvP players, so PvP players have to run it even if they don't want to
Don't get me wrong, I'd love to see servers updating but I can't force them yet I want to support them

[MrIvanPlays]

Someone other than me has watched tom scott 😀

Anyways, according to bStats 50% ( or more, but sure it is not less ) of the servers reporting data run 1.17. There's no good reason to limit yourself to java 8 and 1.8, except of course if you don't wanna deal with the toxic 1.8 community crying on you why your plugin doesn't support it. Sure, backwards compatibility is a good thing but within reason. In minecraft's ecosystem it is good to support 1 major version behind. Go to far and your windows 11 installation has the features of a windows xp, but with a shinier look.

[Jikoo]

Nope it uses Java 8.

[MrIvanPlays]

@lokka30 java 8 is going EOL in 5 months. Sure, you want the api to support minecraft 1.8 without additional stuff, but do you remember when aikar was poking everyone who was using java 7 when mojang decided to enforce java 8? The same thing will happen and this time won't be aikar (only), could be the whole paper community.

[Jikoo]

I would like to point out that the Java 8 share is very steadily dropping too. It's been 5 days and the Java 8 market share is down .5% again. This may just be an issue to put on hold until we hit a particularly interesting feature we want to use. Unfortunately, much as I'd prefer a LTS, I don't think using Java 17 is viable when MC only is pushing Java 16 right now. Hopefully this will be a trend and we'll see 1.18 push Java 17 and then keep up with LTS versions from there out.

[yannicklamprecht]

1.18 is going to use java 17.

I'm so glad that Mojang is finally forcing people to update their Java. I hope they continue this trend with each new Java release, or at least, every new LTS release.

Hopefully they follow the bi yearly cycle. No need to stay on LTS.

[MrIvanPlays]

This really depends whether you can put up with 1-star reviews from crying 1.8 minecraft server owners on the plugin's spigot page. The main reason why I stopped supporting my public plugins and developing such is because of some group of 10 thousand(ish) servers and their owners crying, which then limits the features of the plugin. My opinion here is java 17 (since its LTS) and minecraft 1.17+

[lokka30]

Thanks for your input @MrIvanPlays, @MrNemo64 and @Geolykt,

Here's my own opinion on the matter:

• Treasury doesn't need to raise its Java version unnecessarily, but we can if we need to - it's easy for servers to update.

• It is pointless for Treasury to set a MC version limitation. We don't need any new MC features, we are only looking at newer Java features for now. It is highly unlikely the plugin itself will use features from newer versions.

• I've heard you can change a startup flag and then all old servers can still run the latest Java. I am happy to drop support for any versions that are unable to run the Java version we decide to use, even after setting such flag.

• If we use Java 8 and Minecraft 1.7/1.8 as minimums, I believe we will achieve more success, albeit temporarily as latest-version servers will probably dwarf them at some point. Especially since we are competing with Vault.

• I understand there are some toxic server owners that use older Minecraft and Java versions. But really, who needs to care if they complain. It's a gift that plugins even support outdated software.

[MrIvanPlays]

sure it is a competitor, but do you think that 1.8 server owners will do the switch from vault? do you think 1.8 server owners update their plugins regularly? If a plugin they like says "download treasury to use" sure treasury would get installed, but vault won't get deleted, then you have 2 completely different APIs doing the same thing and different plugins would see player's balance differently and everything gets messy and stuff. Even IF they read the text under "download treasury to use" and delete vault, they won't update the plugins that use vault with their latest versions which support treasury, which then leads to exceptions and owners crying on the developer (especially if it is a toxic one, he will also leave a 1 star review on the plugin's spigot page).

should include api-version: "1.12" in its plugin.yml to prevent unnecessary legacy material support loading

you mean api-version: 1.13

[Jikoo]

sure it is a competitor, but do you think that 1.8 server owners will do the switch from vault? do you think 1.8 server owners update their plugins regularly? If a plugin they like says "download treasury to use" sure treasury would get installed, but vault won't get deleted, then you have 2 completely different APIs doing the same thing and different plugins would see player's balance differently and everything gets messy and stuff. Even IF they read the text under "download treasury to use" and delete vault, they won't update the plugins that use vault with their latest versions which support treasury, which then leads to exceptions and owners crying on the developer (especially if it is a toxic one, he will also leave a 1 star review on the plugin's spigot page).

In your scenario the owner is much more likely to complain to the economy implementation maintainer - Treasury is just an API. While I don't necessarily disagree about the competence of your average 1.8 server owner (I personally do not intentionally support outdated versions beyond maybe a single major version back), you're very hung up on their MC version when what's relevant is Java version. 1.8 is only 8% of servers, 1.7 is another 1%: https://bstats.org/global/bukkit#minecraftVersion

you mean api-version: 1.13

Right you are, whoops.

[lokka30]

I agree with @Jikoo's comments.

I believe the Minecraft version requirement is no longer a consideration since Treasury's plugin side is basic enough to run on as old as 1.7, possibly even older (but obviously we will never provide any guarantees for them). There is one advantage with changing the Minecraft version - if we set it to 1.17+ only, then it is guaranteed that everyone runs Java 16+. But then, we need to ask ourselves - do we really require what newer versions of Java give us, to drop a pretty big chunk of users? I think not.

[lokka30]

Updated the original post to look far nicer. :)

[lokka30]

@Jikoo - did #37 require Java 9+? If not, I think we should stick with Java 8. As much as none of us like it, I think it's the best direction.

[MrNemo64]

I would like to point out that the Java 8 share is very steadily dropping too. It's been 5 days and the Java 8 market share is down .5% again. This may just be an issue to put on hold until we hit a particularly interesting feature we want to use. Unfortunately, much as I'd prefer a LTS, I don't think using Java 17 is viable when MC only is pushing Java 16 right now. Hopefully this will be a trend and we'll see 1.18 push Java 17 and then keep up with LTS versions from there out.

I suppose this is something to discuss when we need to update but instead of latest it may be better to go to java 11 and then update to whatever version everyone is updating to

[lokka30]

My point of view - I really don't mind if we bump to J17. But I want to make sure our choice is done within reason. There is no point in compiling on the latest Java version when we only gain one or few features which are just minor luxuries for Treasury developers anyways, I'm poking at records here.
I completely agree that Java 8 needs to be pushed away by the community, as it steadily is. But the priority here is to make sure as many people can benefit from Treasury as possible without negatively affecting those who are at least bothered to stay on top of what version of Java their server runs.

[MrIvanPlays]

1.18 is going to use java 17.

[lokka30]

1.18 is going to use java 17.

I'm so glad that Mojang is finally forcing people to update their Java. I hope they continue this trend with each new Java release, or at least, every new LTS release.