JDK 10 RFR of 8180767: A return value of zero from java.io.File#lastModified() is ambiguous

[forax at univ-mlv.fr]

Alan,

----- Mail original -----
> De: "Alan Bateman" <Alan.Bateman at oracle.com>
> À: "John Rose" <john.r.rose at oracle.com>, "Rémi Forax" <forax at univ-mlv.fr>
> Cc: core-libs-dev at openjdk.java.net
> Envoyé: Mercredi 24 Mai 2017 22:45:02
> Objet: Re: JDK 10 RFR of 8180767: A return value of zero from java.io.File#lastModified() is ambiguous

> On 24/05/2017 21:11, John Rose wrote:
> 
>> :
>> This seems right to me.  As a casual user of core-libs I would be
>> less likely to use File in new code, and take a second to look for the
>> better replacement, if it were in fact solidly deprecated.
>>
>> Could someone file a bug/rfe to follow this up?  Debate about the ultimate
>> worthiness of File could then be attached to the bug.
> There was deliberate decision back a few years back not to deprecate
> File. At the time then the bar to add @Deprecated was very high and an
> API needed to be very toxic.

java.io.File is toxic too, the way it deals with the file name encoding is something i would like to think as a thing of the past.

Also Path is not only a replacement for java.io.File, it is also more modern., you have the fact that by default, the API uses UTF8 as default file encoding, that the API is able to produce Streams, etc. so it mixes better with modern code.

The other problem is that because it's not deprecated, people still using java.io.File in new code and while there is an interropt between Path and File, the burden goes to the developer that uses Path instead of the one that use File because Path is a more general abstraction than File so the conversion from Path to File can fail.

> Looking at now then several methods could
> be candidates to deprecate as they are inherently broken, deprecating
> the entire class might be too much. 

We are at the starts of 10, if things goes wrong, we can backtrack to your solution.

> One other thing that was tried out
> at the time was to replace the implementation of java.io.File and
> friends to use the new code. This had the benefit of fixing dozens of
> issues (esp. on Windows) in one flick of the wrist. Sadly, subtle
> benefit changes to fix issues are also compatibility issues when dealing
> with an old API. So we chickened out from going there too.
> 
> -Alan

Rémi