[RFC] javadoc: default to not including timestamps

[Martin Buchholz]

On Thu, Jul 24, 2014 at 10:34 AM, Benedikt Morbach <bmorbach at redhat.com>
wrote:

>
> >
> > It depends. My own most-read javadoc is
> >
> http://gee.cs.oswego.edu/dl/jsr166/dist/docs/java/util/concurrent/CompletableFuture.html
> > and that has no release version associated with it. The value of the
> > timestamps may be small, but it is definitely non-zero.
> >
> > It depends on the use case. For Linux operating system deployments, it
> makes
> > a lot of sense to drop the timestamp, especially because the user will
> have
> > a good chance of being able to observe the timestamps of the underlying
> > files.
> I'm mainly arguing that for most use cases, omitting the timestamp
> wouldn't hurt/would be better.
> Doing this upstream in javadoc seemed to be the most future-proof way, as
> it just flips the default.
> And honestly, the current default is suboptimal for both use cases.
> The timestamp should either be in the actual output (not in a comment) or
> not present at all.
>

I disagree.  There's a long tradition of using Show Source for humans or
robots to get more metadata about the web page.  Metadata that might not be
worth putting visibly on the page itself.  This data is not incredibly
valuable, but it is occasionally useful.  The same way that timestamps on
files are occasionally useful.  It's only a few release engineers of the
world that are annoyed by the reproducibility problem (yes, I am also
affected).  So just go and improve your release-diffing tools.

For comparison, you are not helping users if a freshly installed Red Hat
system has every single timestamp set to a fixed meaningless date.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/javadoc-dev/attachments/20140725/bd2e1d5e/attachment.html>