If you want to know why it is bad, just ask. If I need to point you to a better method, just ask ...

If it's weighted one way or another, EVERYONE has the same 'problems'. Doesn't that still make it an equal solution even if it's not random?

Please, because I'm interested, why is it bad?

Pointing to a better method would be very swell of you.

Ok, here is some more info.
If I'm right on the method Ryan is using:
- this build in random Java function does not allow for choosing your own seed.
- this method uses time as seed with milliseconds. For a dice game, this is not good enough (two rolls in the same millisecond are always the same)
- some people question the randomness of this method as the spread is not even. However, I can't confirm this
- If your rounding is not implemented well, you totally screw up the randomness (never use Math.round, instead use Math.floor or something like that)

So what is better?
If you stick with the built in java function, make sure rounding is done correctly.
The Mersenne Twister is said to be better than the random function.

Here are some links:
Mersenne Twister
http://www.codepost.org/browse/snippets/105
About rounding
http://www.quip.net/blog/2006/flash/choosing-random-numbers

DonCrap:
just to some points: why is that milliseconds-problem a problem? on one table no two rolls are done in the same millisecond, apparently.
Why is absolute randomness needed?
Like Noonsaliwah said: dosn´t everybody have the same abberations?

I am almost entirely certain We've been over this before, and that Thegrid has explained this clearly on two distinct occansions, examples provided. Sometimes, streaks happen. Streaks should happen. While 10101010101010101010 Is not likely to be a random string of numbers, 00001011111010011110 is. (literally, I just generated those numbers)

In short: It's as random as it needs to be, shut up.

what? two rolls in the same millisecond = the same result?!!! for both people?!!!

that must be why i keep losing. oh well, at least ive got an excuse

Hey, I didn't invent this! It's a known problem of built in random generators that they are no good for dice and card games. They are only good for generating some random numbers.
Law of the great numbers says that every dice face should have same chance of happening.
Bad dice implementation could be more Gaussian (for example) resulting in a dice where it is unlikely to roll 1 or 6.
Also, the milliseond-problem COULD be a problem, thats something which need to be monitored. And yes, multiple rolls can be done in the same millisecond. Lets say I attack an 8 stack with an 8 stack.
3 of my dices are calculated in the same millisec: 3 times 1
Defender also has 3 dices in same millisec: 3 times 6

@NewOne3: absolute randomness is needed as that is by design the behaviour of a perfect dice. This is very important in every dice and card game. Depending on the implementation this is NOT the same abberation for everyone, as seed is time.

@NoWolf: Streaks will always happen and are no problem. btw, we are not talking about bits, but about 6-faced dics, where eg Gaussian abberation could be a problem. And your example is useless as streaks have nothing to do with randomness! I'm talking about how often dice rolls happen, not when. I dont see why to shut up as I'm only trying to help.

well, it seems you know more about this than most people here (certainly me). the thing is, this doesnt seem like problem that will favor the attacker or defender, or any certain person - it affects everyone equally.
It seems that whether it is to your advantage or disadvantage on any particular dice roll is still completely random, thus making the game completely fair.

Just a thought:
Do you know if the methods you suggested would generate numbers faster/slower than the current system? Thus making time between turns faster/slower and the overall speed of the game faster or slower? If it had an effect in that regard maybe that would be a reason for/against making a change.

NoWolf: technically, the two sets of numbers you proposed are equally unlikely to occur.

"it affects everyone equally." ~Steve
The problem is that it doesn't. If you've ever looked at the output of a standard random function (take C/C++ for example), the numbers are grossly unrandom - it's pathetic, really.

Also: "Do you know if the methods you suggested would generate numbers faster/slower than the current system?" ~Steve

You do know that it takes a fraction of a millisecond to calculate a random number using almost any method and that the reason it may seam slow right now has nothing more to do than a visual effect, right? To implement another method would not mean taking more time between turns.