Filesystem always config directory

[Raugharr]

No description provided.

[sandysimonton]

I recommend changing this to a stateless interface with static methods; public final utility classes imply state but have none. In addition, final classes cannot be hot-swapped by a running vm while interfaces can. I think also that final classes take up space on the heap, which isn't a big deal at all, but it's kind of a head-scratcher to have a stateless object on the heap instead of just in permgen/metaspace where class information lives.

That being said, none of this is wrong and it's mostly personal preference. For further reading, check out articles that discuss replacing public final utility classes with java 8 interfaces or functional interfaces

EDIT: And by the way, you might see some literature about there being no justifiable, OOP-related reason to create an interface without ever intending to extend it. To that I say Java has been moving off of pure OOP concepts since Java 8, introducing functional programming paradigms such as the lambda functions and aforementioned stateless interfaces. As for static utility classes being considered an anti-pattern, well... they help consolidate logic that isn't necessarily related to any single class or feature to one location.

[Raugharr]

That is an appreciated run down on how final works in Java. This class actually can't be a functional interface as there's several other methods that should be in this class (in CampaignMain and the missed UnitUtils classes) like this scattered around and I just wanted to do one since this PR is technically about the Filesystem and didn't want to blow it up to much. If I understand everything correctly the direction this should take is something along the lines of this blog post with the class being called something like UnitCost.

[sandysimonton]

Yeah totally get it about not wanting scope creep to what is essentially a FileSystem edit!

As for the blog post... it's a good idea, but having worked for years with other languages, especially javascript and python, the verbosity of OOP languages is sometimes really hard to get over. The one response to the post was pretty spot-on from my point of view: sure, you can OOP it, but that doesn't mean it's to be done. 3000 lines of code will then bloat to around 12000 given the verbosity of the syntax, assuming the coding paradigm for the project shifts unilaterally to the proposed method of defining utility. And even after all that, you're really just shuffling logic that absolutely has to exist somewhere (new File(...)) into a different class.

I dunno! I'm often caught in between doing what's technically correct and what's practical lol

[sandysimonton]

Actually I was wrong about the public final class. Any object instantiated with the "new" keyword is definitely created on the heap, and theclass definition (bytecode, list of methods, fields, etc.) lives in metaspace. The same goes for Interfaces, but in the case of a public final utility class with only static methods, it's identical to an interface with only static methods because the class is never instantiated (or intended to be, even though a developer technically could call new WhateverUtility()).

What I said about hot-swappable code, however, still remains true - you cannot make a change to the final class and then hot-swap that code out of a running jvm; you have to bounce the environment for the changes to take effect. Do we care? Ehhh maybe in the future?

[Raugharr]

I think for now I will just put this method into the UnitUtils to prevent this ticket from blowing up. I was somewhat hoping the VM could optimize the new away since it was being used like a static method but I guess not.

[sandysimonton]

Just a comment for the EntityUtil that may drive opinion forming about a common paradigm