Add FurnaceBurnEvent.setBurnTime(short burnTime)

[nossr50]

This also deprecates setBurnTime(int burnTime) and fixes its implementation as well Fixes #8178

[Machine-Maker]

Is there a better way? There's no way to write short literals in java right? So you'd now have to do

furnace.setBurnTime((short) 40);

just to avoid it using the deprecated integer method. maybe just throw exception if its too big to be converted to a short?

[emilyy-dev]

Even if the int variant wasn't there you need to either cast to a short or put the number into a short variable to use the method (more specifically, narrowing conversions are not allowed in a method invocation context, and int literals are, well, int literals). Maybe put a @Range annotation on the int parameter? I think clamping the value is a reasonable approach, exceptions are nasty

[Machine-Maker]

Even if the int variant wasn't there you need to either cast to a short or put the number into a short variable to use the method

Oh I figured in the absence of another method that took an int, it'd accept a regular int in a short parameter.

[nossr50]

I don't see the issue with having to cast to short since it's new API and not a change of an existing signature.

[emilyy-dev]

Casting is actively annoying and, when you have a method that does not require casting, it's very easy to miss and forget. Others might think differently but those are my two cents.

[lynxplay]

I'd also be in favour of just limiting the setBurnTime(int) method to Short.MAX_VALUE like done right now for backwards compat. The getter is returning an integer. As pointed out by emily, the @Range annotation could be added to actively inform developers about the constraint on the values even without reading through javadocs.

A new method that requires developers to add rather ugly casts for little to no benefit seems overkill for a problem this small.