[PATCH] 8218268: Javac treats Manifest Class-Path entries as Paths instead of URLs
Donald Kwakkel
dkwakkel at gmail.com
Tue Mar 5 06:11:39 UTC 2019
> 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?
More information about the core-libs-dev
mailing list