Time to make some changes to CloudNet's codebase

So, I “analyzed” CloudNet’s code and oh boy, a lot of work needs to be done. By work I mean actual code and performance optimization, debugging etc.

Most things can probably be done using IntelliJ’s advanced refactoring tools, like searching for something and replacing it, but there’s also stuff on the list which needs to be done by hand.

Pending:

• [approved] Use builders where applicable
• [approved] Create data classes where applicable
• [wip] Replace pure string concats abc += "def" with StringBuilder appends
• [approved] Replace java.io classes with java.nio classes where applicable, might require @Deprecated declarations
• [approved] Some abstract classes and interfaces are waayyy too fat. Requires separation. Might require @Deprecated declarations
• [approved] Return Collection<?> types instead of List<?>, Set<?> or any other extending interface or class of Collection. Might require @Deprecated declarations
• [approved] Use lazy type initialization. (Let a field be initialized by a getter or setter, if the field is null. A lot of stuff in CloudNet might not be needed by anyone or anything)

Work in progress:

• Replace inline statements with block statements
• Calls to functions located in own class should use the this. accessor
• Calls to functions located in super class should use the super. accessor ONLY IF the function is not overridden by the child class
• Try catch blocks shouldn’t silently dispose any exceptions/throwables. (Re-)Throw, print or log them
• Parameter validations shouldn’t silently dispose any exceptions. (Re-)Throw, print or log them
• Re-arrange fields correctly
• Re-arrange functions correctly
• Separate chained field declarations
• Validate the state of parameters (Is the int negative?, is the string blank even though it shouldn’t be?, is the passed varargs array empty?)
• Validate the parameter for null
• Use Guava’s Preconditions instead of own validation class

Done:

• Lombok should not be used in such complex application. The only thing Lombok could be used for is generating #equals(), #hashCode() and #toString(). Using @Getter, @Setter and any other Lombok annotations is highly discouraged blurs a class’ logic

More to come

[issue-label-bot[bot]]

Issue-Label Bot is automatically applying the label feature_request to this issue, with a confidence of 0.95. Please mark this comment with 👍 or 👎 to give our bot feedback!

Links: app homepage, dashboard and code for this bot.

[ghost]

Not using Guava would mean, that we’d have to maintain our own commons. Technically speaking, we’re maintaining something which Google’s maintaining for us, in their own library and probably more efficient. Re-inventing the wheel isn’t the best imho.

Ima change the status of Use Guava's Preconditions instead of own validation class to approved