As far as I can tell, we aren’t using this functionality, but I was wondering about the reasoning behind this change. This seems like a nice bit of flexibility. There are other places (namely the version property) where you allow arbitrary objects, on which toString() is called before the value is used, so this seems a little inconsistent.
Side note: The DSL reference should reflect that passing an arbitrary object to file() is deprecated. The project.file() documentation still implies this is a supported option.
From the migration guide:
Passing custom objects to Project.file() and Project.files() > Passing parameters to Project.file() or Project.files() of a unrecognized type is now deprecated. In the past, any object instance could be passed and Gradle converted this object to a File reference using new File(.toString()).
Passing custom objects to Task.dependsOn() > Passing objects to Task.dependsOn() of other type than the explicit supported and documented is now deprecated. In the past, any object instance could be passed and Gradle mapped this object to a task dependency using toString()).
And from the DSL:
File file(Object path) > Resolves a file path relative to the project directory of this project. This method converts the supplied path based on its type: > * File. If the file is an absolute file, it is returned as is. Otherwise, the file’s path is interpreted relative to the project directory. > * URI or URL. The URL’s path is interpreted as the file path. Currently, only file: URLs are supported. > * Closure. The closure’s return value is resolved recursively. > * Callable. The callable’s return value is resolved recursively. > * Object. The object’s toString() value is interpreted as a path. If the path is a relative path, the project directory will be used as a base directory. A String starting with file: is treated as a file URL.