«

On Fri, 18 Jan 2013 20:50:37 -0800, Knute Johnson
<> wrote, quoted or indirectly quoted someone
who said :

>
>Below is what I ended up with. I'm curious about the UUID. How do you
>create a time based UUID? And does it have less granularity that
>currentTimeMillis?

there are specified formulas for creating UUIDs. I think one way of
rapidly generating them would be to use System.currentTimeMillis for
the high 64 bits and System.nanotime for the lower 64 bits, but I
suspect that would not be considered kosher.

Another would be to use SecureRandom to generate 16 bytes, though that
probably is not as unique as you might hope.


a UUID is not just 128 bits. It has embedded fields that tell you how
it was generated.


--
Roedy Green Canadian Mind Products http://mindprod.com
The first 90% of the code accounts for the first 90% of the development time.
The remaining 10% of the code accounts for the other 90% of the development
time.
~ Tom Cargill Ninety-ninety Law

Roedy Green wrote:
> Knute Johnson wrote, quoted or indirectly quoted someone who said :
>> Below is what I ended up with. I'm curious about the UUID. How do you
>> create a time based UUID? And does it have less granularity that
>> currentTimeMillis?
>
> there are specified formulas for creating UUIDs. I think one way of
> rapidly generating them would be to use System.currentTimeMillis for
> the high 64 bits and System.nanotime for the lower 64 bits, but I
> suspect that would not be considered kosher.
>
> Another would be to use SecureRandom to generate 16 bytes, though that
> probably is not as unique as you might hope.
>
> a UUID is not just 128 bits. It has embedded fields that tell you how
> it was generated.

http://docs.oracle.com/javase/7/docs...util/UUID.html
«The layout of a variant 2 (Leach-Salz) UUID is as follows: The most significant long consists of the following unsigned fields:

0xFFFFFFFF00000000 time_low
0x00000000FFFF0000 time_mid
0x000000000000F000 version
0x0000000000000FFF time_hi
....

«For more information including algorithms used to create UUIDs, see RFC 4122: A Universally Unique IDentifier (UUID) URN Namespace,
http://www.ietf.org/rfc/rfc4122.txt
section 4.2 "Algorithms for Creating a Time-Based UUID".»

--
Lew

On 1/20/2013 12:00 PM, Lew wrote:
> Roedy Green wrote:
>> Knute Johnson wrote, quoted or indirectly quoted someone who said :
>>> Below is what I ended up with. I'm curious about the UUID. How do you
>>> create a time based UUID? And does it have less granularity that
>>> currentTimeMillis?
>>
>> there are specified formulas for creating UUIDs. I think one way of
>> rapidly generating them would be to use System.currentTimeMillis for
>> the high 64 bits and System.nanotime for the lower 64 bits, but I
>> suspect that would not be considered kosher.
>>
>> Another would be to use SecureRandom to generate 16 bytes, though that
>> probably is not as unique as you might hope.
>>
>> a UUID is not just 128 bits. It has embedded fields that tell you how
>> it was generated.
>
> http://docs.oracle.com/javase/7/docs...util/UUID.html
> «The layout of a variant 2 (Leach-Salz) UUID is as follows: The most significant long consists of the following unsigned fields:
>
> 0xFFFFFFFF00000000 time_low
> 0x00000000FFFF0000 time_mid
> 0x000000000000F000 version
> 0x0000000000000FFF time_hi
> ...
>
> «For more information including algorithms used to create UUIDs, see RFC 4122: A Universally Unique IDentifier (UUID) URN Namespace,
> http://www.ietf.org/rfc/rfc4122.txt
> section 4.2 "Algorithms for Creating a Time-Based UUID".»
>

After reading the RFC, using an UUID doesn't sound too practical for the
purposes we have been discussing. It also seems clear that with the
slow clock on a Windows system that one would need a UUID generator that
could be accessed by all interested parties. If that generator were
give two requests in short order, it would have to hold up issuing a new
UUID until the clock had sequenced to the next time.

--

Knute Johnson

On 1/20/2013 3:53 AM, Roedy Green wrote:
> On Fri, 18 Jan 2013 20:50:37 -0800, Knute Johnson
> <> wrote, quoted or indirectly quoted someone
> who said :
>> Below is what I ended up with. I'm curious about the UUID. How do you
>> create a time based UUID? And does it have less granularity that
>> currentTimeMillis?
>
> there are specified formulas for creating UUIDs. I think one way of
> rapidly generating them would be to use System.currentTimeMillis for
> the high 64 bits and System.nanotime for the lower 64 bits, but I
> suspect that would not be considered kosher.

No.

The two parts are related.

And it does not do much to protect against two doing it at the
same time.

> Another would be to use SecureRandom to generate 16 bytes, though that
> probably is not as unique as you might hope.

SecureRandom is probably a lot better.

To be secure the chance of getting duplicate values
if two runs it at the same time should be purely random.

But it can still not guarantee uniqueness.

Arne

On 1/20/2013 4:33 PM, Knute Johnson wrote:
> On 1/20/2013 12:00 PM, Lew wrote:
>> Roedy Green wrote:
>>> Knute Johnson wrote, quoted or indirectly quoted someone who said :
>>>> Below is what I ended up with. I'm curious about the UUID. How do you
>>>> create a time based UUID? And does it have less granularity that
>>>> currentTimeMillis?
>>>
>>> there are specified formulas for creating UUIDs. I think one way of
>>> rapidly generating them would be to use System.currentTimeMillis for
>>> the high 64 bits and System.nanotime for the lower 64 bits, but I
>>> suspect that would not be considered kosher.
>>>
>>> Another would be to use SecureRandom to generate 16 bytes, though that
>>> probably is not as unique as you might hope.
>>>
>>> a UUID is not just 128 bits. It has embedded fields that tell you how
>>> it was generated.
>>
>> http://docs.oracle.com/javase/7/docs...util/UUID.html
>> «The layout of a variant 2 (Leach-Salz) UUID is as follows: The most
>> significant long consists of the following unsigned fields:
>>
>> 0xFFFFFFFF00000000 time_low
>> 0x00000000FFFF0000 time_mid
>> 0x000000000000F000 version
>> 0x0000000000000FFF time_hi
>> ...
>>
>> «For more information including algorithms used to create UUIDs, see
>> RFC 4122: A Universally Unique IDentifier (UUID) URN Namespace,
>> http://www.ietf.org/rfc/rfc4122.txt
>> section 4.2 "Algorithms for Creating a Time-Based UUID".»
>>
>
> After reading the RFC, using an UUID doesn't sound too practical for the
> purposes we have been discussing. It also seems clear that with the
> slow clock on a Windows system that one would need a UUID generator that
> could be accessed by all interested parties. If that generator were
> give two requests in short order, it would have to hold up issuing a new
> UUID until the clock had sequenced to the next time.


Note that randomUUID() does not return type 2 UUID.

Arne

On 1/6/2013 8:46 PM, Twirlip of the Mists wrote:
> On Sun, 06 Jan 2013 20:24:29 -0500, Arne Vajhøj wrote:
>> On 1/6/2013 7:22 PM, Twirlip of the Mists wrote:
>>> 2. How would you develop an OS without the concept of a PID? (No, the sucky
>>> iPhone "OS" doesn't count, since it DOESN'T MULTITASK. )
>>
>> Well - iOS is an OS.
>>
>> It is possible to develop an OS without PID's.
>>
>> DOS did not have PID's.
>
> DOS also lacked multitasking.
>
> And lacking multitasking makes the issue of multiple concurrent instances
> of a single program rather moot, wouldn't you say?

Sure.

But whether the OS has a PID concept or not is a question beyond the
specific usage.

Arne

On 1/7/2013 3:53 AM, lipska the kat wrote:
> On 07/01/13 01:46, Twirlip of the Mists wrote:
>> On Sun, 06 Jan 2013 20:24:29 -0500, Arne Vajhøj wrote:
>>
>>> On 1/6/2013 7:22 PM, Twirlip of the Mists wrote:
>>>> On Sat, 05 Jan 2013 21:56:37 -0500, Arne Vajhøj wrote:
>>>>> On 1/4/2013 1:44 PM, Twirlip of the Mists wrote:
>>>>>> The concept of a PID is platform-agnostic -- all Unices seem to
>>>>>> have it,
>>>>>> MacOS is a Unix nowadays, and newer Windowses have PIDs. It'd be
>>>>>> surprising
>>>>>> if there isn't a platform-agnostic way to get at PIDs -- a POSIX
>>>>>> call that
>>>>>> Windows supports, most likely.
>
> [snip]
>
>> DOS also lacked multitasking.
>>
>> And lacking multitasking makes the issue of multiple concurrent instances
>> of a single program rather moot, wouldn't you say?
>
> Classic ... now watch him wriggle out of that one

You mean that you could not see the irrelevancy of that??

Yuck!

Arne

On 1/7/2013 12:23 AM, Twirlip of the Mists wrote:
> On Sun, 06 Jan 2013 22:11:39 -0500, Arne Vajhøj wrote:
>> On 1/6/2013 10:00 PM, Twirlip of the Mists wrote:
>>> On Sun, 06 Jan 2013 21:41:00 -0500, Arne Vajhøj wrote:
>>>> On 1/6/2013 9:31 PM, Twirlip of the Mists wrote:
>>>>> On Sun, 06 Jan 2013 21:19:59 -0500, Arne Vajhøj wrote:
>>>>>
>>>>>> But there are still a big difference between what has to work on all
>>>>>> platforms and what happens to work on the most popular platforms.
>>>>>
>>>>> If anything genuinely and literally "has to work on all platforms" then
>>>>> we're all ****ed.
>>>>
>>>> Yes.
>>>
>>> Then you recognize the ridiculousness of your position. Good.
>>
>> The fact that a platform agnostic OS features do not exist
>> proves that I am right.
>>
>> You can not get PID in a platform agnostic way.
>
> Using your very rigid definition of "platform agnostic", you can't do
> anything in a platform agnostic way, not even add two and two. Using a
> *useful* definition of "platform agnostic" -- say "runs on anything that
> has an ANSI-compliant C compiler for it" or "runs on anything that has a
> JLS-compliant JVM for it" -- it could conceivably be another story.

ANSI C does require a PID.

And specifying it in Java can not help implement in it Java.

Arne