Develop Reference

How ı build random number not using random library or etc.?

I have to generate random numbers in two different places in the project and I do it using the system clock, but I have to get different numbers in both. How can I do that?

You could use a loop surrounded by calls to System.nanoTime(), then use the least significant bits of their difference as random seed. Once you have, say, 128 bits you can use it as seed for a pseudo random number generator.

There is an article posted in the wiki at java-gaming.org about generating pseudo-random numbers that might be worth perusing. Pseudo-random number generators He shows what he calls an "Old School" method of creating them using a combination of polynomials and modular division. Plus links to other types of PRNGs.

Java weighted random chance centered around a number

I have a program in which I need to generate random numbers that determine various outputs(To explain the exact reason would be too long). In theory a high number (lets say 100,000) is a valid output for my program, but its most likely(but not entirely impossible) going to end up being useless output.
I'd like to generate random numbers that are weighted to be around a "normalized" number.
For example I'd pick a number (10), and the majority of numbers that are randomly generated will be near 10. But there's a small chance the random number could any integer. I currently just use a range when generating the numbers, but this bothers me since numbers outside this range could potentially be valid and useful output.
Is there an easy way to do this without introducing to much overhead or having to map a percentage chances to individual integers?

For positive integers geometric, negative binomial, or Poisson are all possibilities. Java implementations are readily available for all of these.

I would consider this more of a statistics problem than a programming one. I think you want a logarithmic distribution. Here's an example Java implementation.

Why random of 0 to 4 is 1 most of times?

I am using a simple random calculations for a small range with 4 elements.
indexOfNext = new Random().nextInt(4); //randomize 0 to 3
When I attach the debugger I see that for the first 2-3 times every time the result is 1.
Is this the wrong method for a small range or I should implement another logic (detecting previous random result)?
NOTE: If this is just a coincidence, then using this method is the wrong way to go, right? If yes, can you suggest alternative method? Shuffle maybe? Ideally, the alternative method would have a way to check that next result is not the same as the previous result.

Don't create a new Random() each time, create one object and call it many times.
This is because you need one random generator and many numbers from its
random sequence, as opposed to having many random generators and getting
just the 1st numbers of the random sequences they generate.

You're abusing the random number generator by creating a new instance repeatedly. (This is due to the implementation setting a starting random number value that's a very deterministic function of your system clock time). This ruins the statistical properties of the generator.
You should create one instance, then call nextInt as you need numbers.

One thing you can do is hold onto the Random instance. It has to seed itself each time you instantiate it and if that seed is the same then it will generate the same random sequence each time.
Other options are converting to SecureRandom, but you definitely want to hold onto that random instance to get the best random number performance. You really only need SecureRandom is you are randomly generating things that have security implications. Like implementing crypto algorithms or working around such things.

"Random" doesn't mean "non-repeating", and you cannot judge randomness by short sequences. For example, imagine that you have 2 sequences of 1 and 0:
101010101010101010101010101010101
and
110100100001110100100011111010001
Which looks more random? Second one, of course. But when you take any short sequence of 3-4-5 numbers from it, such sequence will look less random than taken from the first one. This is well-known and researched paradox.

A pseudo-random number generator requires a seed to work. The seed is a bit array which size depends on the implementation. The initial seed for a Random can either be specified manually or automatically assigned.
Now there are several common ways of assigning a random seed. One of them is ++currentSeed, the other is current timestamp.
It is possible that java uses System.currentTimeMillis() to get the timestamp and initialize the seed with it. Since the resolution of the timestamp is at most a millisecond (it differs on some machines, WinXP AFAIK had 3ms) all Random instances instantiated in the same millisecond-resolution window will have the same seed.
Another feature of pseudo-random number generators is that if they have the same seed, they return the same numbers in the same order.
So if you get the first pseudo-random number returned by several Randoms initialized with the same seed you are bound to get the same number for a few times. And I suspect that's what's happening in your case.

It seems that the number 1 has a 30% chance of showing its self which is more than other numbers. You can read this link for more information on the subject.
You can also read up on Benford's law.

Seeding a secure random number in java

Will two java.security.SecureRandom instances which are seeded with the same value initially give the same sequence of random numbers?
I am asking this because I want the same sequence of random numbers in both the client and the server. What if both of them are using the same seed value. Will the sequence be the same, or is there any way that the sequence can be made the same?

From the API docs:
If two instances of Random are created with the same seed, and the same sequence of method calls is made for each, they will generate and return identical sequences of numbers.

What if both of them are using the same seed value. Will the sequence be the same?
No, they definitely won't. At least not in Oracle's Java 7 SDK implementation. See my sample code in this SO post. It appears that the implementation may elect to use additional sources of randomness, in addition to the provided seed.

How does the seed value passed to Java's random number generator effect its output?

How does the seed value passed to Java's random number generator effect its output? How would i go about figuring out which numbers it will output if i know the seed value?
Also are some seed values better than others at producing more psudo-randomness than others?

You cannot generate truly random numbers in software, because software is deterministic: given some input, it will in principle always generate a predictable output.
So, to get random numbers, a number of algorithms have been invented that generate sequences of numbers that look random (but are not really - that's why they are called pseudo-random numbers).
Such an algorithm starts with some start value, the seed, and then does some calculations with it to generate the next pseudo-random number.
If the algorithm is any good, then there should be no difference in seed values: one seed value should not be better than any other in generating random numbers.
Often, the current time is taken as the seed value, so that each time you generate a sequence of numbers, you get a different sequence. Note that if you use the same seed value, you will get the same sequence of pseudo-random numbers each time you run it.
If you use pseudo-random numbers for cryptographic purposes, you should be very careful, because if an attacker knows the seed value then he can re-generate the sequence of random numbers which might compromise the security of your system. For really secure systems, people use special hardware-based random number generators, which can generate truly random numbers. Java has a class java.security.SecureRandom to interface with such systems.
See Random number generation on Wikipedia for a lot more detail and information on different algorithms.