Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Received-SPF: pass (asf.osuosl.org: local policy)
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Gump & VM
Date: Thu, 15 Dec 2005 09:53:00 +0100
Message-ID: <F0D7281DAB048B438E8F5EC4ECEFBDDC7D7748@esmail.elsag.de>
Thread-Topic: Gump & VM
Thread-Index: AcYBU4h+gdAJV2dkR5+0mJ2mUHcGMAAAM6Tw
From: =?iso-8859-1?Q?J=F6rg_Schaible?= <Joerg.Schaible@Elsag-Solutions.com>
To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>

C. Grobmeier wrote on Thursday, December 15, 2005 9:46 AM:

>  > So what can we do?
>=20
> I read about timers in the book "killer game programming in java" :-),
> where this things are important. Maybe this is a direction for you.
>=20
> Use the following instead of System.currentTimeMillis():
>=20
> 1) Suns undocumented Class (Java2): sun.misc.Perf

Non-portable

> 2) Java 5: System.nanoTime()

Not JDK 1.3 compatible as the rest of the classes in id

> This two have a higher resolution than currentTimeMillis()
> and could help.

And I doubt that it will help if the OS (or an appropriate daemon task) =
is manipulating the system clock. The problem is not too *less* =
resolution, it is too *much* - at least with daemons adjusting system =
time smoothly. Descreasing the resolution means, that the code might not =
be affected if such a daemon shifts the system time by some millis into =
the past.

- J=F6rg

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org