On Sat, 18 Feb 2006 02:04:25 +0100, "Heiner Kücker"
<mail@heinerkuecker.de> wrote, quoted or indirectly quoted someone who
said :

that is not hard. Ensuring with 100% surely they are unique is harder.

See http://mindprod.com/jgloss/pseudorandom.html#STRINGS

Quoting from it:

Sometimes you want a random String to use as an
almost unique identifier. You could use code like this:


// generating random hex String up to 16 characters long

private static Random wheel = new Random(); // seed with time of day

// ...

/* To get numeric strings with  digits 0-9 try this: */
String almostUniqueAndRandom = Long.toString( wheel.nextLong() &
Long.MAX_VALUE );

/* generate random hex Strings of form
* "0" .. "7fffffffffffffff", a maximum 16 characters long.
* representing 0..Long.MAX_VALUE
* Note there is no such method as Random.nextLong( long ),
* so you have to trim the result to 0..Long.MAX_VALUE yourself.
* To get strings with letters a-f and digits 0-9 try this: */
*/
String almostUniqueAndRandom = Long.toHexString( wheel.nextLong() &
Long.MAX_VALUE );

/* To get strings with letters a-z and digits 0-9 try this: */
String almostUniqueAndRandom = Long.toString( wheel.nextLong() &
Long.MAX_VALUE , 36 );

But what about collisions? How likely are you to  run into problems
with uniqueness? In most cases it is highly unlikely you will  get
duplicates even though Sun's generator generates many more collisions
than a  theoretically perfect true random number generator. Internally
Sun's nextLong  uses only a 32-bit generator and it does not cycle
through all possible 32-bit  patterns. I have written code to compute
the theoretical possibility of a  collision with a perfect true number
generator, and a simulator that exercises Sun's generator and tracks
how well it performs.

 
The code is posted at
http://mindprod.com/jgloss/pseudorandom.html#STRINGS

Fortunately the JavaDocs were created with -use.

http://download.java.net/jdk6/docs/api/javax/tools/class-use/JavaCompilerTool.html
http://download.java.net/jdk6/docs/api/javax/tools/class-use/Tool.html

A few years ago I started a job by documenting the public API of the
company product. Unfortunately it used Collection for returning
collections. That meant I had to supplement the JavaDocs with
additional, untidy use information. The API was changed before release
to use arrays. With generics that would have been unnecessary.

Tom Hawtin

Weblogic ejbc, every JSP compiler that I know about, and Hibernate, all
do dynamic generation of java code.  

It might be useful as a more straightforward approach to problems that
are in the space where BCEL lives.  Also, it occurs to me that such a
feature might be interesting to developers of IDE's, preprocessors, or
compilers.  

The JSR gives some rationale for the API, and it does make some sense.
There's a push to abstract the compiler away from specific dependencies,
particularly, the ones that require javac to be a platform-specific
process, and that require the input to javac to be "files" on a "file
system", idioms that aren't universal.  

James

see http://mindprod.com/jgloss/javacompilertool.html