While working on bug 199136 it turned out that some clients are calling FileUtil.getMimeType(fo, strings) directly and that this method cannot be overriden in FileSystems.
That is unfortunate as it prevents remotefs from optimizing the performance of mime recognition.
Created attachment 109661 [details]
[JG01] Do not introduce an overload of a method differing from the original only in the addition of varargs; it is ambiguous in sources. Use String withinMIMETypes instead. With only one known caller, convenience is not a concern anyway. (If it is necessary to support varargs for callers, use getMIMEType(String mimeType1, String... otherMimeTypes).)
[JG02] Should there be a AbstractFileSystem.Info2 with String mimeType(String, String)?
Re. JG02 - maybe added when needed. Not necessary for remotefs.
Re. JG01 - what is the problem? I think the addition is binary (of course) as well as source compatible.
JG01 - with the proposed change, a call fo.getMIMEType() is visually ambiguous between the current zero-arg method, and the equivalent of fo.getMIMEType(new String). It seems the compiler resolves that to the zero-arg method but why risk confusion?
I don't think we risk a confusion, rather opposite, in current state the behavior is natural:
finds the best mime type possible while
obviously calls the vararg method and checks for the enumerated mimetypes only (usually). Unless more voices disagree, I'd prefer to keep it as proposed.
I'll integrate tomorrow.
Integrated into 'main-golden'
User: Jaroslav Tulach <email@example.com>
Log: #199642: Adding FileObject.getMIMEType(String...)