#14176 closed enhancement (fixed)
Use Java 8 Date API (JSR 310): replace Date by Instant?
Reported by: | Don-vip | Owned by: | simon04 |
---|---|---|---|
Priority: | normal | Milestone: | 21.05 |
Component: | Core | Version: | |
Keywords: | date instant java8 | Cc: | simon04 |
Description
Follow-up from #13376:
Left to be done/discussed: replace 257 occurrences of
Date
byInstant
, or leave it as it is :)
Given the number of deprecated methods in
Date
it's almost if the class is now deprecated itself. I'd say we can change everything that does not impact plugin API.
Compatibility will is a major concern since methods like
AbstractPrimitive#getTimestamp
,AbstractPrimitive#setTimestamp
,Note#getCreatedAt
,Note#getClosedAt
all take/returnDate
s.
Attachments (1)
Change History (40)
comment:1 Changed 14 months ago by
Changed 14 months ago by
Attachment: | 14176-notes.patch added |
---|
comment:2 Changed 14 months ago by
Changing the Note and NoteComment data objects might be a good starting point, since notes are not used by plugins -> attachment:14176-notes.patch
comment:3 Changed 14 months ago by
Coverity found an issue:
*** CID 1451346: Null pointer dereferences (NULL_RETURNS) /src/org/openstreetmap/josm/tools/date/DateUtils.java: 142 in org.openstreetmap.josm.tools.date.DateUtils.parseInstant(java.lang.String)() 136 if (d != null) 137 return d.toInstant(); 138 } 139 140 try { 141 // slow path for fractional seconds different from millisecond precision >>> CID 1451346: Null pointer dereferences (NULL_RETURNS) >>> Calling a method on null object "java.time.ZonedDateTime.parse(str)". 142 return ZonedDateTime.parse(str).toInstant(); 143 } catch (IllegalArgumentException | DateTimeParseException ex) { 144 throw new UncheckedParseException("The date string (" + str + ") could not be parsed.", ex); 145 } 146 } 147
comment:4 Changed 14 months ago by
This looks like a false-positive to me.
java.time.ZonedDateTime#parse(java.lang.CharSequence)
clearly states Returns: the parsed zoned date-time, not null
.
After stepping through the called methods, I found java.time.temporal.TemporalAccessor#query
and java.time.chrono.ChronoLocalDateTime#query
which return null
for other parameters not used here.
comment:18 Changed 13 months ago by
Another issue reported by Coverity:
*** CID 1452256: (NULL_RETURNS) /src/org/openstreetmap/josm/data/gpx/GpxData.java: 298 in org.openstreetmap.josm.data.gpx.GpxData$GpxTrackSegmentSpan.<init>(org.openstreetmap.josm.data.gpx.WayPoint, org.openstreetmap.josm.data.gpx.WayPoint)() 292 private final WayPoint firstWp; 293 private final WayPoint lastWp; 294 295 GpxTrackSegmentSpan(WayPoint a, WayPoint b) { 296 Instant at = a.getInstant(); 297 Instant bt = b.getInstant(); >>> CID 1452256: (NULL_RETURNS) >>> Dereferencing a pointer that might be "null" "at" when calling "isBefore". 298 inv = bt.isBefore(at); 299 if (inv) { 300 firstWp = b; 301 firstTime = bt; 302 lastWp = a; 303 lastTime = at; /src/org/openstreetmap/josm/data/gpx/GpxData.java: 298 in org.openstreetmap.josm.data.gpx.GpxData$GpxTrackSegmentSpan.<init>(org.openstreetmap.josm.data.gpx.WayPoint, org.openstreetmap.josm.data.gpx.WayPoint)() 292 private final WayPoint firstWp; 293 private final WayPoint lastWp; 294 295 GpxTrackSegmentSpan(WayPoint a, WayPoint b) { 296 Instant at = a.getInstant(); 297 Instant bt = b.getInstant(); >>> CID 1452256: (NULL_RETURNS) >>> Calling a method on null object "bt". 298 inv = bt.isBefore(at); 299 if (inv) { 300 firstWp = b; 301 firstTime = bt; 302 lastWp = a; 303 lastTime = at;
comment:21 Changed 13 months ago by
This ticket is mentioned in the changelog for milestone 21.04. Is it fixed or is there anything left to do?
comment:22 Changed 13 months ago by
Thanks for double checking / asking. It's ongoing work (maybe half way through)...
comment:29 Changed 13 months ago by
Owner: | changed from team to simon04 |
---|---|
Status: | new → assigned |
comment:30 Changed 13 months ago by
Milestone: | → 21.05 |
---|---|
Resolution: | → fixed |
Status: | assigned → closed |
comment:33 Changed 13 months ago by
comment:34 Changed 13 months ago by
Because I intentionally modified this code in r17840. I could have been more clear on that in the commit message...
In 17653/josm: