[RFC] [openjdk] provide milisecond modification timestamps

[Andrew Hughes]

----- Original Message -----
> Am Montag, den 23.04.2012, 14:22 -0400 schrieb Andrew Hughes:
> > ----- Original Message -----
> > > Am Montag, den 23.04.2012, 12:41 -0400 schrieb Andrew Hughes:
> > > > ----- Original Message -----
> > > > > diff -r 8ac52c85f9e9
> > > > > src/solaris/native/java/io/UnixFileSystem_md.c
> > > > > --- a/src/solaris/native/java/io/UnixFileSystem_md.c	Wed Feb
> > > > > 23
> > > > > 15:49:19
> > > > > 2011 -0800
> > > > > +++ b/src/solaris/native/java/io/UnixFileSystem_md.c	Sat Apr
> > > > > 21
> > > > > 10:11:26
> > > > > 2012 +0200
> > > > > @@ -197,7 +197,10 @@
> > > > >      WITH_FIELD_PLATFORM_STRING(env, file, ids.path, path) {
> > > > >          struct stat64 sb;
> > > > >          if (stat64(path, &sb) == 0) {
> > > > > -            rv = 1000 * (jlong)sb.st_mtime;
> > > > > +            if(sb.st_mtimensec != 0)
> > > > > +            	rv = (jlong)sb.st_mtimensec / 1000000;
> > > > > +            else
> > > > > +                rv = 1000 * (jlong)sb.st_mtime;
> > > > >          }
> > > > >      } END_PLATFORM_STRING(env, path);
> > > > >      return rv;
> > > > > 
> > > > > 
> > > > > 
> > > > 
> > > 
> > > Hi Andrew,
> > > 
> > > > This looks a sensible improvement to me.  I can add it to the
> > > > IcedTea
> > > > repository.
> > > 
> > > But it only looks sensible :-) The correct patch against jdk7 is
> > > attached!
> > > 
> > > I looks like the field st_mtim.tv_nsec is just an extension to
> > > the
> > > second accuracy provided by st_mtim.tv_sec.
> > > 
> > 
> > Ah right, yes this is the same way clock_gettime works, which we
> > use
> > to implement System.nanoTime in GNU Classpath:
> > 
> >   result = (jlong) tp.tv_sec;
> >   result *= (jlong)1000000000L;
> >   result += (jlong)tp.tv_nsec;
> > 
> > The difference here is that the Java API means that most of the
> > accuracy
> > gain is lost in the division.  I wonder if there is a case for a
> > deeper
> > patch that allows nanosecond accuracy to be fully exposed?
> 
> At least not for File.lastModified() which returns "a long value
> representing the time the file was last modified, measured in
> milliseconds since the epoch".
> 

Yes, I guessed that.  But it doesn't mean another method couldn't be added.
But...

> [me having a quick look at the new stuff in 1.7]
> 
> Oh, nice! Java 7 seems to have FileTime and
> Files.getLastModifiedTime().
> 

...I'm guessing Oracle will just point to this new API.  Does it provide
nanosecond accuracy?

> But I guess the 1.7 API is no option for icedtea-web (yet)?!
> 

I don't see why IcedTea-Web is relevant to this discussion?

> > 
> > > But I don't know if this compiles on Solaris, etc... But
> > > according to
> > > the man page of stat() it should compile if compatible to
> > > POSIX.1-2008.
> > > 
> > > > 
> > > > Have you signed the Oracle Contributor Agreement (OCA) so it
> > > > can
> > > > also
> > > > be upstreamed to OpenJDK?
> > > 
> > > Not yet...
> > > 
> > > thomas
> > > 
> > > 
> > > 
> > 
> 
> 
> 
> 

-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: 248BDC07 (https://keys.indymedia.org/)
Fingerprint = EC5A 1F5E C0AD 1D15 8F1F  8F91 3B96 A578 248B DC07