Java 8 java.time Classes – Missing getMillis() Method Explained

javajava8

Java 8 has a whole new library for dates and times in the package java.time which is very welcome thing to anyone who has had to use JodaTime before or hassle with making it's own date processing helper methods. Many classes in this package represent timestamps and have helper methods like getHour() to get hours from timestamp, getMinute() to get minutes from timestamp, getNano() to get nanos from timestamp etc…

I noticed that they don't have a method called getMillis() to get the millis of the time stamp. Instead one would have to call method get(ChronoField.MILLI_OF_SECOND). To me it seems like an inconsistency in the library. Does anyone know why such a method is missing, or as Java 8 is still in development is there a possibility that it will be added later?

https://docs.oracle.com/javase/8/docs/api/java/time/package-summary.html

The classes defined here represent the principal date-time concepts, including instants, durations, dates, times, time-zones and periods. They are based on the ISO calendar system, which is the de facto world calendar following the proleptic Gregorian rules. All the classes are immutable and thread-safe.

Each date time instance is composed of fields that are conveniently made available by the APIs. For lower level access to the fields refer to the java.time.temporal package. Each class includes support for printing and parsing all manner of dates and times. Refer to the java.time.format package for customization options…

Example of this kind of class:
https://docs.oracle.com/javase/8/docs/api/java/time/LocalDateTime.html

A date-time without a time-zone in the ISO-8601 calendar system, such as 2007-12-03T10:15:30.

LocalDateTime is an immutable date-time object that represents a date-time, often viewed as year-month-day-hour-minute-second. Other date and time fields, such as day-of-year, day-of-week and week-of-year, can also be accessed. Time is represented to nanosecond precision. For example, the value "2nd October 2007 at 13:45.30.123456789" can be stored in a LocalDateTime…

Best Answer

JSR-310 is based on nanoseconds, not milliseconds. As such, the minimal set of sensible methods are based on hour, minutes, second and nanosecond. The decision to have a nanosecond base was one of the original decisions of the project, and one that I strongly believe to be correct.

Adding a method for millis would overlap that of nanosecond is a non-obvious way. Users would have to think about whether the nano field was nano-of-second or nano-of-milli for example. Adding a confusing additional method is not desirable, so the method was omitted. As pointed out, the alternative get(MILLI_OF_SECOND) is available.

FWIW, I would oppose adding the getMillis() method in the future.

Related Solutions

Java – Iterators versus ‘cursors’ in Java

Forgive me if I'm not quite grasping what you're after, but it does seem as if you're conflating the concepts of Iterator and Factory/Builder.

Let me just lay out some thoughts here.

The Iterator pattern works well for a homogenous collection of objects that you want to hand out through a common interface. For example, you have a collection of Strings and you want them dealt out in a particular order so you use a Comparator (behind the scenes) and your consuming code only has to call next() a few times to achieve it's objective.

The Factory pattern creates an instance of an Object according to a given specification - sometimes provided as arguments, sometimes inferred. The Builder pattern is similar but is usually geared towards completing a single step along the way to the completion of an instance of a composite collection of Objects.

It seems from your code example that you want a mechanism that allows you to create an instance of an Object (of varying type) in response to a given number of calls. Perhaps a sequence like this:

next() -> getType1() -> String with "Hello"
next() -> getType2() -> Integer with 4
next() -> getTypeN() -> some function applied -> some type returned

and so on.

If this is what you're after, then this approach violates the Principle of Least Surprise. As a developer if an object is being quietly mutated behind the scenes, I'd like to know about it since I want to know the threading and performance issues that could arise.

Since the problem you appear to face is one of maintaining a collection of objects between stateless web calls you're probably better off using a simple List and provide the index to the current entry as part of the response to the client. When the client requests the contents of the List simply hand it to JAXB to marshal it into XML/JSON (it'll use an Iterator).

This approach keeps your code simple, and therefore prevents developers after you looking at the code and saying WTF?

Java 8 Mixins – Are Interfaces with Virtual Extension Methods the Same?

Yes, these are mixins. They aren't as powerful as Scala traits (no ability to have a reference to the parent "self" object and its properties or methods), but the default methods can implement meaningful behaviour and so can be more more than sticking plasters to stop existing code breaking when an interface is extended.

The limited power of default methods seems to be deliberate, judging by the various informed discussions of the feature. The designers' advice is that default methods should generally not contain the concrete implementation of a method but accept a lambda or reference to a concrete class, either of which can provide the implementation. Example here

Best Answer

Related Solutions

Java – Iterators versus ‘cursors’ in Java

Java 8 Mixins – Are Interfaces with Virtual Extension Methods the Same?

Related Topic