search

ThreeTen / threeten

This project was the home of code used to develop a modern date and time library for JDK8. Development has moved to OpenJDK and a separate backport project, threetenbp.
http://threeten.github.io/
191 stars 37 forks source link

Duration: getNano should be getNanos #346

Closed terje7601 closed 10 years ago

terje7601 commented 10 years ago

In the Duration class, I believe "getNano" should be renamed to "getNanos" for consistency reasons.

jodastephen commented 10 years ago

You are correct, this is a mistake. Sadly I suspect it is too late to be fixed, but that is up to Oracle.

terje7601 commented 10 years ago

I'm a layman when it comes to the JCP, but: why can't this be fixed either way, since JSR-310 in itself is independent of Oracle & still in "Proposed Final Draft" status (i.e. hasn't had its "Final Release" yet)? Else, what is the use of having a "Proposed Final Draft" when the API & its RI are effectively already frozen because of the JDK 8 schedule? Moreover, it's still 2 months until the release, the method is only used in 2 classes (Duration & its test class TCKDuration) & Java 8 is really the only release this typo can be properly fixed. Anyway, I know it's not up to you to decide on this, so let's hope common sense will prevail here.

RogerRiggs commented 10 years ago

Only show stopper bugs are being accepted for JDK 8 currently. JSR 310 is not independent of Oracle due to its integration into SE 8. The SE 8 efforts are focused on stabilizing the tests on 3 platforms and it is a very large effort. A change made at this point involves updating the specification (easy), modifying the RI (pretty easy except for the 3 concurrent approval processes), modifying the tests (not too hard), migrating the modified tests to the (JCK) (a different group), since JSR 310 is integrated into SE 8 then the artifacts produced for SE 8 (javadoc/specs, etc) need to be redistributed and approved by the JSR 337 expert group. Common sense also includes making the conscious tradeoff of the value of the change and the costs. With the current spelling, the method will appear in the same place in javadoc and for IDE completion so it will have little/no impact on developers.

terje7601 commented 10 years ago

Thanks for putting things into perspective. I do realize SE 8 is a huge undertaking, but I assumed there would be shortcuts in the whole process to fix oversights like this (a typo in a public API).

RogerRiggs commented 10 years ago

Unfortunately, at this late stage it is very difficult to fix anything but the most severe issues.