[PATCH] 8218268: Javac treats Manifest Class-Path entries as Paths instead of URLs

[Jonathan Gibbons]

Donald,

While it was reasonable to raise the spec issues on core-libs-dev, 
any/all questions about
javac code should be addressed to compiler-dev at openjdk.java.net.

That being said,

  * any comment labelled "// TODO" in new code seems questionable
  * the copyright date on the test is wrong and should probably be 2019
  * the test uses tabs instead of spaces
  * direct writes to System.err are probably wrong


-- Jon

On 03/13/2019 02:38 PM, Donald Kwakkel wrote:
> Attached patch with tests so first the bug for java11 can be fixed and
> backported.
> Would be nice if someone can guide me how to continue with this and/or
> can reply on my previous questions.
>
> Op di 5 mrt. 2019 om 07:11 schreef Donald Kwakkel <dkwakkel at gmail.com>:
>>> On 02/28/2019 01:06 PM, Alan Bateman wrote:
>>>> On 28/02/2019 20:58, Jonathan Gibbons wrote:
>>>>> Looking at the revised JAR specification, approved in [1], it is
>>>>> disappointing that the spec contains text which is specific to
>>>>> a JAR file being used in a classloader:
>>>>>
>>>>> |The resulting URLs are inserted into the search path of the class
>>>>> loader opening the context JAR immediately following the path of the
>>>>> context JAR. Any duplicated URLs are omitted.|
>>>>>
>>>>> That text would seem not to apply to javac and other tools that may wish
>>>>> to process the class files in a JAR file.
>>>> That should be fixed as it should apply at compile-time too.
>>>>
>>>> -Alan
>>> |Agreed it might be good to fix it if possible. All the preceding text
>>> is good, and can be handled by javac. The only questionable bit is the
>>> text "Any duplicated URLs are omitted" which could be moved up a bit in
>>> the spec to a new paragraph, and maybe rephrased to use "ignored"
>>> instead of "omitted". If that were done, all the stuff about class
>>> loaders could be taken as non-normative text.
>> So if I am correct the answer to Question 2 is: Yes, behavior must be the same.
>>
>> What are the next steps to take for this? And can someone also answer my
>> other questions?:
>>
>> Question 1: Where can I find the tests for these changes?
>> Question 2: Where should the common code for this be located?
>> Question 3: Is it an idea to first implement below patch and backport
>> that, and in addition as new ticket implement the new behaviour also
>> for javac?
>> Question 4:Is this they way to do it, or is there a better way to
>> provide debug information to users running javac?