"No source files for package" in a directory with accent characters

[Jonathan Gibbons]

Robert,

One final comment: while this thread has been in the context of javadoc, 
the code in question is part of javac, and so the changes in behavior 
apply to the use of @files with both javac and javadoc commands.

-- Jon


On 09/03/2019 11:43 AM, Robert Scholte wrote:
> Jon,
>
> this is exactly the information I was looking for.
> Based on this we can safely fix it in our plugin.
>
> thanks,
> Robert
>
> On Tue, 03 Sep 2019 20:28:43 +0200, Jonathan Gibbons 
> <jonathan.gibbons at oracle.com> wrote:
>
>> Robert,
>>
>> I may have misunderstood your original question;  I thought you were 
>> talking about the encoding used for the files generated by javadoc 
>> (which is an area where we've had problems in the past) ... but it 
>> seems like you may be referring to the file encoding used for any 
>> @-files used on on the command line, right?
>>
>> Generally the code was substantially modified in JDK 9 with
>> https://bugs.openjdk.java.net/browse/JDK-8173308
>>
>> but the change you observe looks like the result of
>> https://bugs.openjdk.java.net/browse/JDK-8214514
>> which was fixed in 12.
>>
>> It was not intentional to change to use UTF-8 for @-files in JDK 9, 
>> 10, 11: it was the result of the default used by 
>> Files.newBuffereredReader when no Charset argument was provided. The 
>> fix, in JDK-8214514, was to explicitly specify Charset.defaultSet() 
>> as the second argument of Files.newBufferedReader.
>>
>> -- Jon
>>
>>
>> On 09/03/2019 11:15 AM, Robert Scholte wrote:
>>> Hi Jon,
>>>
>>> It was not my analysis, I'm just the messenger.
>>>
>>> The -docencoding is UTF-8 by default
>>> The -charset uses the value of docencoding by default.
>>>
>>> The issue seems to be related to the encoding of the @options 
>>> argument we pass to the javadoc tool.
>>>
>>> Here's the thing we do:
>>>
>>>         /* default to platform encoding */
>>>         String outputFileEncoding = null;
>>>         if ( JAVA_VERSION.isAtLeast( "9" ) )
>>>         {
>>>             outputFileEncoding = StandardCharsets.UTF_8.name();
>>>         }
>>>         try
>>>         {
>>>             FileUtils.fileWrite( optionsFile.getAbsolutePath(), 
>>> outputFileEncoding, options.toString() );
>>>         }
>>>
>>>
>>> Robert
>>>
>>> On Tue, 03 Sep 2019 19:37:15 +0200, Jonathan Gibbons 
>>> <jonathan.gibbons at oracle.com> wrote:
>>>
>>>>
>>>>
>>>> On 09/03/2019 10:06 AM, Robert Scholte wrote:
>>>>> This is the title of an issue reported for the Maven plugin[1]
>>>>>
>>>>> Based on the analysis some involved developers came to the 
>>>>> conclusion that the outputFileEncoding for Java 9, 10 and 11 was 
>>>>> changed to UTF-8, but since Java 12 it behaves again like Java 8.
>>>>>
>>>>> Can this be confirmed with the related ticket or are we facing a 
>>>>> different issue?
>>>>>
>>>>> regards,
>>>>> Robert Scholte
>>>>>
>>>>> [1] https://issues.apache.org/jira/browse/MJAVADOC-614
>>>>
>>>> Robert,
>>>>
>>>> The issue for the most recent change in this area was JDK-8183582
>>>> https://bugs.openjdk.java.net/browse/JDK-8183582
>>>>
>>>> That being said, that issue was fixed in 10, so does not align with 
>>>> the timeline in your analysis.
>>>>
>>>> Can you provide details of the values of the -docencoding and 
>>>> -charset options you may be using when you observe the different 
>>>> behaviors.
>>>>
>>>> -- Jon
>>>>