Zero-length array allocation inspection (idea)

[RusTit]

Text: Reports on allocations of arrays with known lengths of zero. Since array lengths in Java are non-modifiable, it is almost always possible to share zero-length arrays, rather than repeatedly allocating new zero-length arrays. Such sharing may provide useful optimizations in program runtime or footprint. Note that this inspection does not report zero-length arrays allocated as static final fields, as it is assumed that those arrays are being used to implement array sharing. And also I removed two methods. They are the same as those of the parent class.

[RusTit]

@Nedelosk please review.

[KorDum]

Objects.equals(desc, EmptyHelper.EMPTY_STRING)

Hmm. Here is an code shorter:

desc.equals(EmptyHelper.EMPTY_STRING)

But why do you write own constant for an empty string?

import net.minecraft.util.StringUtils;
StringUtils.isNullOrEmpty(desc)

or

import org.apache.commons.lang3.StringUtils;
desc.equals(StringUtils.EMPTY)

[RusTit]

My bad. Java is not my main programming language. I was looking for a constant, but missed it. I'll correct it a bit later.

[Nedelosk]

@RusTit Why are you adding final to every local var ?

[temp1011]

It can increase performance at runtime I believe but seems a bit controversial https://stackoverflow.com/questions/154314/when-should-one-use-final-for-method-parameters-and-local-variables

[RusTit]

@Nedelosk

1. This does not break anything?
2. There may be a performance gain (or maybe not).
3. Should not be harm from this.
4. I have already started, I will finish in this PR only module core (so it is safer).

[RusTit]

5.Makes code more standardized. Some files / methods already use the final in args, vars, for cycle.

[RusTit]

Two latest commits fix border (lines near slots element) in compartment search window: Fix:

[RusTit]

Search window has also bug with icon painting. ~~~According to my tests it is related to z-state of elements. In common situation all gui elements painted on 0 (zero) level.~~~ But Search window is created on top. Later then slots are repainted - it will produce bug. Take a look on green ceramic block on first row (third from left). On this pic and pic above (last). If slot of compartment contain any item (block of wheat) it's mask will glitch on item icon in same position in search window. It also glitching in scrolling. @Nedelosk @temp1011 what is best way to fix it? My idea with z-state (I think need only some changes in ControlSlot and RenderUtil to provide custom z-level painting)

[KorDum]

The key word final is usually used for constants in Java or readonly instance class level fields (initialize in constructor):

private final int count;
public SomeClass(int count) {
    this.count = count;
}

Constants at compilation are inlined in bytecode in a number of cases. It doesn't give any advantages in performance, it is a message to the programmer. By and large this clutters up the code and I would recommend removing everywhere (except for constants).

Java compiler itself optimizes the code when assembling to bytecode. JRE itself optimizes the bytecode when reading. https://stackoverflow.com/questions/8354412/do-java-finals-help-the-compiler-create-more-efficient-bytecode

[temp1011]

Unfortunately I don't really know anything about GUIs. However, I think the point about final things is interesting.

[mezz]

Most of these changes look good but I agree with @KorDum on final. Most of the existing final you see in the code are probably from the decompiler. It's not really that helpful in most cases. One thing I like to use it for is on int that are constant, since it is easy to read when you have some int that are obviously being mutated and some that are not.

[RusTit]

Well, what to do with the refactoring already done. Should I remove the new finals.

[mezz]

I think you should remove the new finals, sorry.

[RusTit]

No problem, but it can take some time.

[mezz]

Please do not add more commits on to this PR, it needs to be reviewed and merged but that gets harder with more commits. You can create a new PR for more changes.

[RusTit]

Ok, but to make clear, where is still some bugs:

1. Item icons painting on second layer. (Some description is above).
2. Event key passing in ComponentCompartmentInventory.java and WindowCompartment.java (read my dialog with Nedelosk).

[RusTit]

Item icon painting bug appears not only in the search window. You can also see it in the slider (in which custom tab settings are set).

[mezz]

If you have specific fixes for the changes made in this PR, I think that is fine. I am just worried that this PR is going out of control, it seems to be fixing too many different things.

[RusTit]

Not yet. I do not know how to fix a bug with rendering. I will fix the error with the key a little later with separate commits (will be last in this PR)

[RusTit]

Apparently there is no bug with keys. I did debugging by checking the passed string-keys through the events, in everything is ok. P.S. but the bug with the renderer I can not solve myself.

[KorDum]

Tabs indent or spaces?