There is a huge difference between low-static and no-static.
The former is good.
The latter is stupid.
Also, your problem is not static. Your problem is bad code design. :point:
That’s not what we call a bug, that’s a compilation error.
Cas 
Touché.
No-static proponents = walls of text.
Low-static proponents = 4 - 5 sentences of sensible arguments.
Let’s drop Math from java!
Saying static is bad is like saying using new is bad, and threads, and nullable values, and using other people’s code is bad.
If you don’t know how to use it, you’re going to have a bad time.
Using new IS bad! Well, it depends of course but what I’m trying to point out is the usefulness of factories!
Factories handle the creation of objects with the “new” keyword and also handles all their dependencies.
A crude example is if you want to create a mob in your game you’d need to do something like this without a factory:
{
int x = 0;
int y = 0;
Mob m = new Mob(this, this.level, this.input, this.audio, x, y);
this.level.entities.add(m);
}
With a factory you could do something like this instead:
{
int x = 0;
int y = 0;
this.level.entities.add(this.factory.newMob(x,y));
}
I guess you’ve used ‘new’ for your factory somewhere, and I’m pretty sure those factories use ‘new’ too in some extra lines of code you didn’t show 
You can almost completely replace ‘new’ with for example an IoC framework, but that’s imho rarely an advantage if all you want to do is release a small game.
I understand your point (factories are a useful pattern), but that’s quite a sweeping statement.
Of course the factories are using new somewhere. I just wanted to point out how simple factories (no need to import huge frameworks into your small games either) solves the problem that arises when opting to not use static methods.
If you’re not using a factory, and not using static methods - then you’re “stuck” manually inserting the required dependencies and references etc which is a huge pain that grows exponentially with project size.
In the crude example the missing factory code could simply be:
Mob newMob(int x, int y) {
Mob m = new Mob(this.main, this.level, this.input, this.audio, x, y);
return m;
}
Saying using new is bad is too black & white, I can’t take such statements seriously and then as a result of that I can’t take the person making it seriously to be brutally honest.
SOMETIMES a factory type solution makes sense. Sometimes a simple creation method is enough, no need to create new classes for such things. And sometimes just using new to construct an object is more than enough. And sometimes creating a singleton or using statics works.
Use the right tool for the job - that’s the only pattern that applies always.
Using new isn’t bad, but misusing it is (as in, you don’t know when to use new and when to pool objects). That’s my point. It all comes down to how large the object is, how expensive it is to instantiate, and how frequently you will be allocating temporary ones.
Do people stop reading posts after the first sentence or paragraph and reply with their gut instinct?
Of course, that’s why I mention it in my original post.
I agree. A person who writes a review on a book based on the first sentence in the book is someone I also can’t take seriously.
I’m not so sure, sometimes using the tool that’s already in your hand works just fine.
If you’d bother to read the whole post you’d realize it’s about how useful factories are (especially in non-static environments) - not about not using new.
Statics are often the only way to do certain things. While I try to keep global variables to a minimum, sometimes the alternative is worse then just having a global.
The only architecture I’ve used that makes it easy to avoid any statics is something like the actor model where everything is message passing.
Most of the time, statics in my code are reserved for thread safe variables that are used to share data across threads, such as thread safe queues or maps. I also find that the need to use those patterns shows up more on the server then the client.
I think a better overall goal to shoot for that will also give you very few statics is making your code thread safe. There are a lot of advantages to being able to reuse chunks of client code on the server (game logic especially), and not being thread safe makes it a real pain.
I’ll agree with you there for the sake of the argument.
Then why oh why did you have to muddy the waters by opening up with that statement? Because where I come from what you say first matters the most to you, the rest is to backup the statement you’re making.
You can’t blame me for misunderstanding you, you did it all by yourself. Thanks man.
;’<
static variables aren’t thread safe. You need to do things in synchronized {} blocks or use things like AtomicInteger and or use stuff from the java.util.concurrent package (like concurrent queues and maps etc)
everytime someone posts in this topic a little kitten dies, sad day, sad day … :emo:
Not if it is a static final kitten…
Not if we implement a kill function…
KITTEN.kill();
True, but a static final kitten should be immutable.
One of the reasons why Eclipse (and any other IDE/engine) is lousy at tracking static variables is because doing so is a problem whose complexity grows exponentially. I work for a static analysis company (not to be confused with static variables) and if you think about it, Eclipse is compiling the method behind the scene and then running through hypothetical execution scenarios to determine possible problems e.g. null pointer dereferences.
Static source-code analysis can easily track local variables because what can access that instance is limited to the current execution thread. Static global variables, on the other hand, can be written to by any thread at any time! Hence no assumptions can be made about what value it contains at anytime.