Jar manifest and EOF character (code 26)
Philipp Kunz
philipp.kunz at paratix.ch
Mon Nov 4 06:38:33 UTC 2019
Hi Max,
Even if it was easy to implement, I don't think we actually would want
it. Hopefully not put too much to the point, it sound like last century
operating with punch cards. The discussed portion of the specification
refers to "EOF character (code 26)" and also I am not talking about an
end of a file or input stream. Nowadays I don't see fit. However easy
or difficult to implement, in either case, I'd opt for removing that
sentence about EOF characters in manifests.
I doubt that changing the reading of manifests, particularly at their
ends, is a promising prospect at the moment. I tried to make this point
already with references [3] through [14] in the previous mail below and
I added one new reference [1] of that sort. It would be easy to
implement only if it was not for compatibility, I figure. If a
consensus or an agreement can be found for removing the discussed
sentence from the specification we are kind of lucky that the code does
not have to be changed. No way I'd want to jump to conclusions here but
changing the specification around the EOF character only and not the
code is possible without waiting for the other issues related to
parsing an insufficiently terminated last line of a manifest which have
been stuck for a while now.
Regards,Philipp
[1]
https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-February/058774.html
On Mon, 2019-10-14 at 09:41 +0800, Weijun Wang wrote:
> Hi Philipp,
> Although I also think this feature might be useless, I feel hesitated
> to just remove it. How about implement it and let it stay useless? I
> assume this will not break any existing test or app if no one is
> actually using the character. Hopefully it's easy to implement.
> On the other hand, if there is really a EOF char at the end, there
> will be a behavior change. If that EOF is at the end an attribute
> line, that line is ignored now, and it should be visible after the
> change and this looks like a good thing. If that EOF is after a
> newline, it will be useless anyway.
> Also, my understanding is that hash/signature in a signed jar file
> are calculated on raw bytes and old signed jars can still be
> verified. We should take care to use the original raw bytes and not
> the result of Manifest::write, but I think your previous fixes in
> this area had already handled this correctly.
> Just my $0.02.
> Thanks,Max
> > On Oct 11, 2019, at 2:11 PM, Philipp Kunz <philipp.kunz at paratix.ch>
> > wrote:
> > Hi,
> > The Jar File Specification [1] states that,
> > > If the last character of the file is an EOF character (code 26),
> > > the
> > EOF is treated as whitespace. Two newlines are appended (one
> > foreditors that don't put a newline at the end of the last line,
> > and oneso that the grammar doesn't have to special-case the last
> > entry, whichmay not have a blank line after it).
> > But I can't see that this is actually the case. See the attached
> > simpletest that indicates that this statement is not implemented.
> > See also potentially remotely related bugs [2] and [3] which both
> > referin my opinion to EOF as the end of the byte stream as opposed
> > to theEOF character 26.
> > After nobody has fixed this point inside of many years I tend to
> > assumethat it is not at all necessary or useful. However, I cannot
> > understandthe intention behind it or how that statement got there
> > in the firstplace and hence might not be aware of the full context.
> > Considering the activity about the last line of a manifest
> > notterminated by a line break resulting in that line ignored
> > unexpectedly (see [3] through [14]) I doubt that it is promising to
> > attempt toimplement the EOF according to the specs.
> > Instead I'd rather like to propose to update the specification
> > byremoving the quoted statement.
> > I'm not sure if the specification [1] has changed since 13 or where
> > themost up to date one is.
> > Regards,Philipp
> >
> >
> > [1]
> > https://docs.oracle.com/en/java/javase/13/docs/specs/jar/jar.html#notes-on-manifest-and-signature-files
> >
> > EOF-related:[2] https://bugs.openjdk.java.net/browse/JDK-7148584
> > [3] https://bugs.openjdk.java.net/browse/JDK-4639129
> >
> > Last line break required or missing related:[4]
> > https://bugs.openjdk.java.net/browse/JDK-4274235
> > [5] https://bugs.openjdk.java.net/browse/JDK-4894998
> > [6] https://bugs.openjdk.java.net/browse/JDK-4333854
> > [7] https://bugs.openjdk.java.net/browse/JDK-6594305
> > [8]
> > http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-February/058774.html
> > [9] https://bugs.openjdk.java.net/browse/JDK-4489716
> > [10] https://bugs.openjdk.java.net/browse/JDK-4639129
> > [11] https://bugs.openjdk.java.net/browse/JDK-4625822
> > [12]
> > https://stackoverflow.com/questions/21859417/header-must-be-terminated-by-a-line-break-eclipse-manifest-mf
> > [13] https://bugs.eclipse.org/bugs/show_bug.cgi?id=377249
> > [14] https://bugs.java.com/bugdatabase/view_bug.do?bug_id=4274235
> >
> > <20191011-manifest-eof.patch>
More information about the core-libs-dev
mailing list