Yes it’s because in java2d if you had 471 particles you had 471 colors.
Back to your code:
So what would happen if you create 5 red particles.
Then you take one particle and set the color to blue. What color will the 4 other particles have? You use color.set(…)
Yes you got it 
I would change:
In Particle.class
/** The color of the particle. */
private final Color color = new Color();
and in the constructor:
color.set(COLOR);
in RainbowSnow.class
private final Color snowColor = new Color();
/**
* Updates the snow.
*/
public void update() {
snowColor.set(red/255f, green/255f, blue/255f, 1.0f);
if(counter == 10) {
for(int i=0;i<RANDOM.nextInt(1800) + 120;i++) {
newParticle(snowColor, RANDOM.nextInt(8), 40);
}
counter = 0;
} else {
counter++;
}
...
Are you always writing so many comments in your code? That’s nice
Immutability for the win!
Should all functional languages rise! ;D
(This is probably a dangerous statement in a java forum :persecutioncomplex: … Anyways, go on, I didn’t want to derail : )
Thanks for the help Phil. I have the code looking similar to what you put, but I kept it closer to my original way so that the transition looks better.
if(counter == 10) {
for(int i=0;i<RANDOM.nextInt(1800) + 120;i++) { newParticle(new Color(red/255f, green/255f, blue/255f, 1.0f), RANDOM.nextInt(8) + 2, 40); }
counter = 0;
} else {
counter++;
}
Working for up to 200k particles, when I hit 300k it slows down to a snails crawl.
No problem
The quizz is done, the participant won, the quiz-(not even close to master) has to go :
But anyways, an Immutability-modifier would be awesome in java.
private immutable Object o; //if you try to change a value inside o an ImmutableExeption will be thrown
It’s not that easy… There is reflection too and stuff like that. It’s possible to change the [icode]char[][/icode] inside a String via reflection, although the String should actually be immutable.
Isn’t that particularly nasty since the strings are interned, any other string ‘objects’ that have (had) the same text as the one you change will also change? I may be wrong, been a while since I messed around with interning strings.
It doesn’t have to throw an exception if you use reflection.
it just should throw an exception if you do something like
class Whatever{
String myString;
immutable Whatever w; //if you try to change a value inside o an ImmutableExeption will be thrown
void test(){
w.myString = "wasd"; //throw exception
w.setString("wasd2");
}
void setString(String s){
this.myString = s; //throw exception
}
}
So what you describe is almost what [icode]final[/icode] does, but you want it to recursively mark all fields of that method as final…
It doesn’t need to be an exception. It would be much better if it was a compiler error. Or else you might not notice your error it until some of your users has a PC that makes your code jump into some strange if-branch and then fail. The compiler can immediately see if you tried to change something from an Object that was marked to be [icode]immutable[/icode], just like it’s with [icode]final[/icode].
I don’t think this would be too useful. There is even a problem with My first point, that I just noticed 
… Let’s take LibGDX’s Color class as an example. If you’d mark it as immutable (and you had the compiler error method that I described in point 1) it wouldn’t compile, because there’d be a compiler error with the [icode]Color.set()[/icode] method… Therfore it would make sense to use Exceptions, yeah…
Hrm…
I don’t like the idea of adding more runtime errors, though. I think the future lies in compilers that find out that your program is wrong before it even executed once. They find the bugs for you easily, because the coder is constrained in what he can do so that It’s easy for the compiler to spot bugs. That’s exactly why compile-time type-checkers were invented. They didn’t want you to accidently use your “Color” as String, because that’d be impossible. They constrain us, though. We can’t simply cast a “Vector3f” into a “Color”, though, even though in C it would work…
So then you fight back and use typeclasses and other interesting magic, make everything immutable, safer, and suddenly Haskell.
[quote]I think the future lies in compilers that find out that your program is wrong before it even executed once.
[/quote]
It does seem to be the way things are progressing. It has a certain elegance to it that I feel is quite attractive to us programmers, but so far is also quite elusive.