Jar manifest and EOF character (code 26)

Tue Nov 12 17:58:00 UTC 2019

I have created a CSR, https://bugs.openjdk.java.net/browse/JDK-8233722 <https://bugs.openjdk.java.net/browse/JDK-8233722>,  to address the EOF issue.  The CSR has been approved.

Unless I hear any last minute reservations, I will move forward with the update to the JAR spec.

Best
Lance
> On Nov 4, 2019, at 1:38 AM, Philipp Kunz <philipp.kunz at paratix.ch> wrote:
> 
> 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>

 <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>