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

Donald Kwakkel dkwakkel at gmail.com
Wed Mar 13 21:38:03 UTC 2019

Attached patch with tests so first the bug for java11 can be fixed and
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?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 8218268.patch
Type: text/x-patch
Size: 8407 bytes
Desc: not available
URL: <https://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20190313/22fd0784/8218268-0001.patch>

More information about the core-libs-dev mailing list