Re: When to use float (in teaching)
On May 8, 4:14 pm, Mark Thornton <mthorn...@optrak.co.uk> wrote:
Lew wrote:
Mark Thornton wrote:
Nevertheless, it can be important to check our assumptions. Long ago I
did check for atomic assignment found that it didn't work. Just a few
days ago I found some code that depended on the behaviour of
Timestamp.getTime() as exhibited by JVMs up to 1.4. In 1.4, Sun
changed the behaviour and left the documentation very confusing
(especially for those aware of the previous behaviour).
All right, I'll bite. What was the previous behavior, and how did it
change in Java 1.4?
In this case I was just adding an historical note that there was some
basis for believing the assignments not to be atomic, but today it is
about as valid as suggesting that Java is slow!
Prior to 1.4 Timestamp.getTime() always returned a multiple of 1000;
that is an exact second. The fraction was then obtained from the
getNanoseconds method. From 1.4 the getTime() method returns
nanoseconds/1000000. The value returned by getNanoseconds hasn't
changed, so code that relied on the pre 1.4 behaviour tends to get an
overall time where the fractional seconds are counted twice.
I suspect this change resulted from an effort to reduce the problems
arising from mixing java.util.Date with java.sql.Timestamp (notably
comparisons didn't work properly).
Looking at the Javadocs for the Java 6 version of java.sql.Timestamp
<http://java.sun.com/javase/6/docs/api/java/sql/Timestamp.html>
I see:
Note: This type is a composite of a java.util.Date and a separate nanosec=
onds value.
Only integral seconds are stored in the java.util.Date component.
Since the change you describe for java.sql.Timestamp is a change in
specification, then my earlier arguments against reliance on bugs do
not apply to this case. Relying on an obsolete specification is not a
programmer's right. It's like relying on pre-Java 5 code that has a
variable or method named 'enum' and being angry that it violates Java
5's rules.
Apache commons-lang relied on a class-initialization bug that violated
the JLS extant at the time they relied on it, and when the bug was
fixed, Apache refused to correct their mistake. That's a horse of a
different color.
Also, since this is an API class, not part of the Java language
itself, and not mentioned in the JLS, my arguments about reliance on
the JLS don't apply to this case. Javadocs are generated from the
implementation of an API, and therefore are the product of an
interpretation of the specification for that API, not the
specification itself. There can be, and clearly sometimes are, errors
in the implementation of Javadocs just as in the Java source itself.
I am claiming that Java programmers have a right to rely on the JLS
for the version of Java we're using. The JLS is the rigorous,
normative description of Java's rules. I am also claiming that
violating those rules just because a bug happens to let you do so is
extremely bad practice.
--
Lew